Object Hash vs. object Array preference

T

Thomas 'PointedEars' Lahn

VK said:
I'm not arguing with you any more. There are reasons to argue only if
the final aim is to find the true between each other arguments. It's a
vasted time if any fact is accepted if, and only if, it fits to the
books of canon.

The language implementations you tested with are based on that canon,
more, they claim to be compliant to it. Any empirical proof you provide,
considering that the result is indeed unique (especially timing tests in
such short intervals are unreliable, taking caching, multitasking and other
factors to affect run-time into account) is perhaps valuable regarding a
specific version of a specific user agent on a specific computer, however
it does not bear meaning as a general test case and so it inappropriate
to refer to for general design decisions. Especially as you are merely
making unqualified assumptions what may or may not be without being able
to provide any proof for it, because we are dealing with Closed Source
except of Mozilla/5.0 based user agents.

You see, there are a whole lot of ifs here. Ignoring them in
your argumentation certainly do not make it a more convincing one.


HTH & HAND

PointedEars
 
L

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn said:
And how does the first paragraph of the Array object specification fit in?
There is clearly either replacing or additional property handling defined
for those objects, see below. ....
The specification seems to produce a contradiction by itself here.
In section 8.6.2 in restricts the difference to the [[Put]] method,
in section 15.4 it specifies "special treatment to a certain class
of property names."

No contradiction. There is special treatmet for a certain class of
property names (array indices and "length"). The special treatment
only occurs when you write to properties of those names, but it is
still special treatment.
For all other property names, the [[Put]] method on arrays works as
the [[Put]] method on non-array language objects.

/L
 
V

VK

Thomas said:
The language implementations you tested with are based on that canon,
more, they claim to be compliant to it. Any empirical proof you provide,
considering that the result is indeed unique (especially timing tests in
such short intervals are unreliable, taking caching, multitasking and other
factors to affect run-time into account) is perhaps valuable regarding a
specific version of a specific user agent on a specific computer, however
it does not bear meaning as a general test case and so it inappropriate
to refer to for general design decisions. Especially as you are merely
making unqualified assumptions what may or may not be without being able
to provide any proof for it, because we are dealing with Closed Source
except of Mozilla/5.0 based user agents.

You see, there are a whole lot of ifs here. Ignoring them in
your argumentation certainly do not make it a more convincing one.

I see... All empiric experiments are based on imperfect real world
systems so their results are not reliable in any given case. From the
other side ECMA specifications are based on pure mental compositions
without interception with the real world - therefore they are perfect
by their very nature and they don't need any further proof or
questionning. ECMA contains all knowledge and all answers - you just
need to open your sool to *believe* and all your questions will be
answered forever.
:)

Full disclosure: I'm not so much preoccupated with the exact definition
of objects, arrays and hashtables: I'm not a CS theory professor. But
as an A.I. hobbist I'm really interested in the process the mind is
escaping the real world facts to save the predefined internal model.

You may enjoy (I did) reading the article "JavaScript: Playing Numbers
Game":
<http://www.devx.com/webdev/Article/17215/0/page/3>

Besides some very intersting facts about the JavaScript internal
mechanics, it was for me a wonderful example of ability to make totally
wrong conclusions based on totally correct facts - just to keep the
world "as it should be".
 
T

Thomas 'PointedEars' Lahn

VK said:
Thomas said:
The language implementations you tested with are based on that canon,
more, they claim to be compliant to it. Any empirical proof you provide,
considering that the result is indeed unique (especially timing tests in
such short intervals are unreliable, taking caching, multitasking and
other factors to affect run-time into account) is perhaps valuable
regarding a specific version of a specific user agent on a specific
computer, however it does not bear meaning as a general test case and so
it inappropriate to refer to for general design decisions. Especially as
you are merely making unqualified assumptions what may or may not be
without being able to provide any proof for it, because we are dealing
with Closed Source except of Mozilla/5.0 based user agents.

You see, there are a whole lot of ifs here. Ignoring them in
your argumentation certainly do not make it a more convincing one.

I see... All empiric experiments are based on imperfect real world
systems so their results are not reliable in any given case. From the
other side ECMA specifications are based on pure mental compositions
without interception with the real world - therefore they are perfect
by their very nature [...]

No, you have still not understood.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Lasse said:
Thomas 'PointedEars' Lahn said:
And how does the first paragraph of the Array object specification fit
in? There is clearly either replacing or additional property handling
defined for those objects, see below. ...
The specification seems to produce a contradiction by itself here.
In section 8.6.2 in restricts the difference to the [[Put]] method,
in section 15.4 it specifies "special treatment to a certain class
of property names."

No contradiction. There is special treatmet for a certain class of
property names (array indices and "length"). The special treatment
only occurs when you write to properties of those names, but it is
still special treatment.

Not true. It also happens when reading those properties.

var a = [1, 2, 3];
alert(a["2"]); // yields 3 (in Firefox 1.0.7/Linux)


PointedEars
 
V

VK

Thomas 'PointedEars' Lahn wrote:
No, you have still not understood.

Dead lock... as usual...

Let's us call arrayObject[Integer] vs. arrayObject[String] benchmark
advantage as "undocumented wrong behavior demonstrated by many
browsers"? I'm fine with that. At least we could move on some coding
ideas out of all these theoretical disputes.

And still read the article I mentioned - it seemed to me (I may be
wrong) that the magic of the number 4294967295 in many programming
languages (not only JavaScript) was not totally clear by you.
 
L

Lasse Reichstein Nielsen

VK said:
Honnest the God I did not plan to make a trolling thread here - I
really wanted to find the most productive solution for my methods.
Unfortunately I have to conclude that I'm on my own in that as everyone
else is using wrong model, that gives totally wrong benchmark
predictions and totally wrong explanations (or no explanation at all)
to the benchmark results.

I think we have been talking about the subject from different angles.
If you entire point is that the current implementations implement
objects with special handling of numeric indices, then it appears
to be correct. The explanation using "casting" and "Baby Care" isn't
very clear, though. It can be stated much shorter, e.g.:

ECMAScript uses strings for property names. Doing a lookup on
a number gives the same as first converting the number to a
string.

Many current implementations optimize lookup by numbers by using
the numbers as keys internally, instead of their string representation.
That means that a lookup with a number index is faster in such an
implementation, than using a string representation of the number.
This is the opposite of a literal implementation of the ECMAScript
algorithms, which would use time converting the number to a string
first.

This optimization is commonly applied to all objects, not just arrays.

/L
 
L

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn said:
Not true. It also happens when reading those properties.

var a = [1, 2, 3];
alert(a["2"]); // yields 3 (in Firefox 1.0.7/Linux)

There is no *special* treatment here.

The variable "a" refers to an array object. It has properties named
"0", "1", "2", and "length". Evaluating a["2"] looks up the value
of the property "2", which is the number 3. The same would be
true of the object
{"0":1, "1":2, "2":3, "length":3}
The [[Get]] method executes the same steps for the array as for
this object. Nothing special happens for the array.

/L
 
V

VK

Lasse Reichstein Nielsen wrote:
I think we have been talking about the subject from different angles.
If you entire point is that the current implementations implement
objects with special handling of numeric indices, then it appears
to be correct. The explanation using "casting" and "Baby Care" isn't
very clear, though. It can be stated much shorter, e.g.:

ECMAScript uses strings for property names. Doing a lookup on
a number gives the same as first converting the number to a
string.

Many current implementations optimize lookup by numbers by using
the numbers as keys internally, instead of their string representation.
That means that a lookup with a number index is faster in such an
implementation, than using a string representation of the number.
This is the opposite of a literal implementation of the ECMAScript
algorithms, which would use time converting the number to a string
first.

You just did the first really crucial step in your new life: you
questionned The Book and tried to find a new reading to old texts.
Still long way to go but the step is done.
;-)

Here's some homework to do: ;-)

[1]
var hashObject = {};
var arrayObject = [];

/* Hashtable and Array are different objects
* with different structure and method/property sets:
*/
alert(hashObject instanceof Array); // false
alert(arrayObject instanceof Array); // true

/* But both Hashtable and Array are extending
* basic Object constructor, so whetever Object
* has, Hashtable and Array have too:
*/
alert(hashObject instanceof Object); // true
alert(arrayObject instanceof Object); // true

[2]
var tmp = 1;
alert(typeof tmp); // "number"
tmp = "";
alert(typeof tmp); // "string"
tmp = true;
alert(typeof tmp); // "boolean"

/* Does the above prove that there are no
* numbers, strings and booleans in JavaScript
* but only some amorphium "data holder"?
* Of course not! It just shows that JavaScript
* implements run-time typezation if needed.
*/

[3]
JavaScript was never written by ECMA standards.
ECMA standards are written by exploring pre-existing closed source
JavaScript engine (in Netscape Navigator). Whatever the team did not
see or did not understand properly went into papers as well as totally
correct descriptions (the right part still constitutes the total
majority of ECMA specs).

P.S. God damn! And I hopped to work closer on my jsFileManager this
week-end... :-(
 
T

Thomas 'PointedEars' Lahn

Still no proper quoting. Why am I not suprised?
Dead lock... as usual...

I beg your pardon? I tried to explain to you shortly and in great length
that your very approach of evaluation of code efficiency is based on a
major basic misconception and you did not even bother to look into what it
took me much of my free time to detail for you. Now you dare accusing me
of blocking the discussion? Go away!


PointedEars, Score adjusted
 
R

Randy Webb

VK said the following on 11/13/2005 10:39 AM:

JavaScript was never written by ECMA standards.

That line, in and of itself, explains 100% why I don't have any more
faith in what ECMA says than I do. It's a good theory about how things
should be, but its a crappy indicator of how things really are. When the
browsers (most notably MS) actually match what ECMA says (or vice versa)
then I will start worrying about it. Until then, I care more about what
the browsers actually do instead of what ECMA says they should do.

<snip>
 
V

VK

Randy said:
That line, in and of itself, explains 100% why I don't have any more
faith in what ECMA says than I do. It's a good theory about how things
should be, but its a crappy indicator of how things really are. When the
browsers (most notably MS) actually match what ECMA says (or vice versa)
then I will start worrying about it. Until then, I care more about what
the browsers actually do instead of what ECMA says they should do.

Do not try to be more royalist than the king himself ! :-D

ECMA 262 Specifications ("ECMA") is a description of a working engine
(Netscape Navigator 4.5) made through the extensive testing and
consultations with Netscape specialists. The main task was to give such
description of this engine that anyone could build another engine which
does exactly the same things.
It doesn't cover at all (and it couldn't) the exact implementation of
each feature. Also some errors has been made in some descriptions. So
"fully ECMA compliant" engine is an engine that mimics each position in
the ECMA even if the internal process is completely different. So if
ECMA says "And here we have a string" and you (oops!) using integers,
you be good boy - take this integer, convert it into string and provide
to the interface.
But when performance becomes the primary issue you indeed should work
on the actual implementation - exactly as you're going from C++ on
assembly codes to get the last drop from your PC.
 
R

Richard Cornford

News posts carry a 'References' header that describes the sequence of
messages and responses into which the new message fits. Your message has
the 'References' header:-

References:
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>

- in which no posts by me appear at all. The final message Id in that
header is the message to which your message is claming to be a response,
and that message was written by Lasse Reichstein Nielsen. So why are you
posting a reply to Lasse but quoting me and are apparently replying to
me?

Is it rally that difficult for you to actually reply to the message to
which you seem to want to be replying?
I'm not arguing with you any more.

You never do argue anyway. Al you do is make a series of bizarre
statements, someone tells you why you are wrong (or irrelevant, or
misguided, or whatever) and you either ignore them compliantly or whine
about being criticised. It gives the impression that you don't have any
real justification for the assertions that you make and are indeed
making it all up off the top of your head.
There are reasons to argue only if the final aim is
to find the true between each other arguments.

Yes the point of arguing is to come to some mutual understanding. But if
you will never explain what you are talking about when you say things
like "Array's Object envelope", "the length flag", "turns on JavaScript
Baby Care mechanics", " Invalid array index value", "Array-mode to
Hashtable-mode", "interpreter both add new array element [33] and new
property "33"", " Object<>Array back and forth casting", etc, there is
little hop of understanding. Without explanation of what you mean when
you say these strange things the impression is that you are just
gibbering incoherently.
It's a vasted time if any fact is accepted if, and only if,
it fits to the books of canon.

What facts? You still have not stated what the urban legend you spoke of
was supposed to be, or stated whatever it was that was supposed to be
"dispropaganded". All you did was post a sequence of code statements
that demonstrated behaviour in accordance with the specification. As the
theory is that conforming ECMAScript implementations will exhibit
behaviour that conforms to the specification, and so that the
specification can be employed as a guide to the behaviour of conforming
ECMAScript implementations (indeed that it is the only guide to the
behaviour of such implementations) you appear to have expended effort
demonstrating nothing.
Honnest the God I did not plan to make a trolling thread
here - I really wanted to find the most productive solution
for my methods.

And by "productive solution" do you by any chance mean that you want to
know which type of property accessor, using which type of property name
provides the fastest results when used with Objects and Arrays. You
don't have to go off into the made-up world of VKScript to find that
out, you just have to do some experiments, as Lasse did.

It is also a good idea to actually think about the results you get.
Lasse produced a range of results form 406 to 1093 milliseconds for one
million loop iterations. And timed:-

1. The resolution of the Identifier - obj - against the scope
chain, 1000000 times.
2. The resolution of the Identifier - prop - against the scope
chain, 1000000 times.
3. The retrieval of the value from - obj - using prop (the
part of the process that is of interest here) , 1000000 times.
4. The resolution of the identifier - x - against the scope
chain, 1000000 times.
5. The assignment of the value retrieved to x, 1000000 times.
6. The overhead of each iteration of the while loop (including
the post decrement operation) , 1000000 times.
7. The creation of a Date object, once.

So a worst-case per-loop timing of 0.001093 milliseconds, in which the
operation of interest is only one of a number of operations performed,
suggests that this is a quest for speed in the wrong place. Particularly
when you consider that results will vary between implementations (as
they will rarely use the same optimisations except by coincidence), that
the timing resolution is no better than 10 milliseconds, that the type
of CPU and the CPU type plus OS combination can be a significant factor
and that any test are likely to be performed on a multitasking OS with
the number of background tasks influencing the outcome.

So there is unlikely to be a definitive answer to the question, and the
actual differences are going to be so tiny as to have little impact on
the results.
Unfortunately I have to conclude that I'm on my own
in that as everyone else is using wrong model,

Most people (with the possible exception of the mentally ill) would take
the discovery that nobody else can be persuaded that they are right as
reasonable gourds for questioning their beliefs.
that gives totally wrong benchmark predictions and totally
wrong explanations (or no explanation at all) to the
benchmark results.

Who is giving benchmark predictions? The explanation for actual
implementations producing performance differences that do not correspond
with those that would be expected if the ECMA algorithms were slavishly
followed by implementations is that implementations are not required to
follow the algorithms, only to behave as if they were following the
algorithms. Internal optimisations are allowed. ECMA 262 defines
behaviour not performance.

Where you are constantly disagreed with is in your desire to make up
stories to explain behaviour that is already well defined. Those stories
do not help people understand the task and problems of programming using
javascript.
That would be like asking someone who's using flat model
of Earth for an advise of the best way from Europe
to China through America.
<snip>

If, finding yourself in a minority of one, you don't like the appeal to
numbers, have you considered the appeal of effective outcomes. You will
recall that you spent months struggling with writing effective event
handlers, misunderstood and disregarded numerous explanations of what
was actually happening (given by some the people you consider to be
using the wrong model) and still (based on the rubbish in some of your
recent posts on the subject) do not fully understand the mechanics of
event handlers. And all this time you were surrounded by people using
the 'wrong model' who were having no trouble successfully using event
handlers. This 'wrong model' is being promoted because it is an
effective way of understanding the behaviour of the language being used,
it produces results.

You are the one falling to get to China.

Richard.
 
R

Richard Cornford

VK wrote:
Here's some homework to do: ;-)

[1]
var hashObject = {};
var arrayObject = [];

/* Hashtable and Array are different objects

In what sense are they different objects. Any Array or Object instance
will inevitably be a distinct object, but there is nothing presented
here to indicate that they are different types of object. And as
javascript only has one Object type any claim that they are different
type of object would need some evidence to support it.
* with different structure and method/property sets:

So, possibly still the same type of object with different initialisation
([[Prototype]], [[Class]] and [[Put]] assignments) as required by ECMA
262.
*/
alert(hashObject instanceof Array); // false
alert(arrayObject instanceof Array); // true

100% in accordance with ECMA 262.

So what is the point that you think you are making with this? And how
meaningful is it when you consider:-

function myObject(){
; //...
}
myObject.prototype = [];
var x = new myObject();

alert(x instanceof Array); //alerts true;

- when - x - is certainly not an Array?
/* But both Hashtable and Array are extending
* basic Object constructor,

Justify the use of 'extending' in a language that is not class-based and
where augmentation is the specified process of turning the native object
into an Array.
so whetever Object
* has, Hashtable and Array have too:
*/
alert(hashObject instanceof Object); // true
alert(arrayObject instanceof Object); // true

100% in accordance with ECMA 262.

But all that is being said is that there is an object on the prototype
chain of both Arrays and objects. The same is also true of regular
expressions and functions:-

alert(function(){;} instanceof Object); //alerts true
alert(/a/ instanceof Object); //alerts true
[2]
var tmp = 1;
alert(typeof tmp); // "number"
tmp = "";
alert(typeof tmp); // "string"
tmp = true;
alert(typeof tmp); // "boolean"

/* Does the above prove that there are no
* numbers, strings and booleans in JavaScript
* but only some amorphium "data holder"?

It shows that values have types (but not that many) and
variables/properties can hold any type. 100% in accordance with ECMA
262. So what is the point you are trying to make here?
* Of course not! It just shows that JavaScript
* implements run-time typezation if needed.

You are making up your own terminology again, it doesn't promote your
cause. There is no type-conversion (and certainly no casting) going on
here. All that is happening is that you are assigning values of
different types to a variable/property that can hold any type.
*/

[3]
JavaScript was never written by ECMA standards.
ECMA standards are written by exploring pre-existing closed
source JavaScript engine (in Netscape Navigator). Whatever
the team did not see or did not understand properly went into
papers as well as totally correct descriptions (the right part
still constitutes the total majority of ECMA specs).

One of the drawbacks with never reading ECMA 262 for yourself is that
you would miss the list of contributors. That list includes Brendan
Eich, ever heard of him?

<URL:
http://wp.netscape.com/comprod/columns/techvision/innovators_be.html >

Richard.
 
V

VK

Richard said:
News posts carry a 'References' header that describes the sequence of
messages and responses into which the new message fits. Your message has
the 'References' header:-

References:
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>

- in which no posts by me appear at all. The final message Id in that
header is the message to which your message is claming to be a response,
and that message was written by Lasse Reichstein Nielsen. So why are you
posting a reply to Lasse but quoting me and are apparently replying to
me?

Is it rally that difficult for you to actually reply to the message to
which you seem to want to be replying?

Must be wrong schooling:- I always to following the main thread so my
post would add up at the and of the line w/o making new thread branch.
Sometimes few more replies are already staying in front of the post I'm
answering to. Also sometimes I'm doing a cummulative reply to several
posts as they are close connected. I used to think that the exact
indication of the author of the quote is more convenient than post
headers lookup. Am I so wrong?
 
V

VK

Cummulative answer to Richard Cornford:

If you go to my OP you'll see that I did not want I did not make any
"points". I simply asked for the fastest algorythm for my method. Now
read all these 30+ posts and see what did I get and who's really making
a final pointless point.

Pre-declared Array object served with proper integer index values gives
me 6 sec time gain on my %windir%\temp\ directory (hundreds of files
and folders) in comparison with Hashtable and 3 sec over mis-treated
Array (used one time as hash, another time as array). You may imagine
what is even 3 sec for usability issue. To keep this time gain though I
have to stay with Array w/o temporary transformations Array > Hash >
Array.

I'm asking for an advise and what kind of bs am I getting instead:

- There is no array and hash, so doesn't matter what are you using -
read ECMA
- But there is a benchmark difference on all browsers I've tested !
- There is no any difference, your tests are not accurate - read ECMA
- Can you provide a code for an accurate test?
- No test can be accurate as too many circumstances are involved - read
ECMA instead
etc. etc. etc.

That would drive crazy any less stable person, my sense of humor helps
greatly but not always.

OK, listen, guys: I asked for the best performance algorythm, you
explaned me that any is equally good as I'm dealing with the same
entity. I listened you, I'm saying thank you for you help, I'll think
about it.

Topic is over.
 
R

Richard Cornford

^^^^^
Can't you get this right just the once?

Must be wrong schooling:- I always to following the main thread

There is no such thing as a "main thread" in Usenet.
so my post would add up at the and of the line

What "line"?
w/o making new thread branch.

It is in the nature of Usenet conversations to branch, there is no need
and no point in trying to avoid that, and your actions do not achieve
that anyway.
Sometimes few more replies are already staying in front
of the post I'm answering to.

And that is relevant to what exactly?
Also sometimes I'm doing a cummulative reply to
several posts as they are close connected.

And you shouldn't be doing that anyway.
I used to think that the exact indication of the
author of the quote is more convenient than
post headers lookup.

Headers are used to organise the presentation of posts in newsreaders,
they are more important to the presentation of threaded conversation
than anything else.
Am I so wrong?

You certainly appear not to have any idea of what you are doing, again.

Richard.
 
R

Richard Cornford

VK said:
Cummulative answer to Richard Cornford:

An "answer" that does not contain a single answer to any of the
questions that I asked. It is that attitude that is getting in the way
of your actually learning anything useful here.
If you go to my OP you'll see that I did not want I did
not make any "points".

I looked at you original post and found it too incoherent and inadequate
to be addressed with anything but guesswork and elected not to bother.
I simply asked for the fastest algorythm for my method.

That was not apparent, but as you did not elaborate your method it would
not be practical to suggest what may be faster or slower.
Now read all these 30+ posts and see what did I get and
who's really making a final pointless point.

So you have no intention of explaining what all of that nonsense you
posted was supposed to be about?
Pre-declared Array object served with proper integer index
values gives me 6 sec time gain on my %windir%\temp\
directory (hundreds of files and folders) in comparison with
Hashtable and 3 sec over mis-treated Array (used one time as
hash, another time as array). You may imagine what is even 3
sec for usability issue. To keep this time gain though I have
to stay with Array w/o temporary transformations
Array > Hash > Array.

Hundreds of files? You strategy must be appallingly bad is only hundreds
of items are procuring such appalling performance. If you were talking
about thousands of items you may be looking at seconds.
I'm asking for an advise and what kind of bs am I getting
instead:

Your asking for advice is being ignored. Mostly because you are
incapable of expressing you question coherently. What is happening is
that you are making bizarre assertions and refusing to provide any
explanation when asked what you are talking about.
- There is no array and hash, so doesn't matter what are
you using - read ECMA
- But there is a benchmark difference on all browsers I've tested !

You have presented no evidence that you have tested anything, or how you
have tested it. Given your record on testing logic and methodology, and
your atrocious Math, your clams alone are unlikely to be given credence.
- There is no any difference, your tests are not accurate
- read ECMA
- Can you provide a code for an accurate test?

No, accurate testing is not possible. I can write tests that produce
more accurate results, but I have already explained the flaws in your
testing a couple of times so you should be able to work out the logic of
the necessary tests for yourself. (or use the archives to find superior
examples to work from).
- No test can be accurate as too many circumstances are involved -
read ECMA instead
etc. etc. etc.

That would drive crazy any less stable person, my sense of
humor helps greatly but not always.

OK, listen, guys: I asked for the best performance algorythm, you
explaned me that any is equally good as I'm dealing with the same
entity.

That may have been your 'understanding' of what has been explained, but
that fact that that statement is incoherent indicates that it was not
what actually was explained, and that you did not understand.
I listened you, I'm saying thank you for you help, I'll think
about it.
<snip>

That will make an unexpected change.

Richard.
 
T

Thomas 'PointedEars' Lahn

VK said:
ECMA 262 Specifications ("ECMA")

ECMA is the acronym for the European Computer Manufacturers Association,
an international standardization body. It is _not_ the name of one of the
standards published by that body.

There is only one ECMA-262 (ECMAScript) Specification, yet there are several
editions of it. The most recent one is edition 3.
is a description of a working engine (Netscape Navigator 4.5) made through
the extensive testing and consultations with Netscape specialists.

No, it is not! What you write is absolute complete utter nonsense!
As can be read in its preface (any edition), for example

,-<http://www.mozilla.org/js/language/E262-3.pdf>
|
| [...]
| Brief History
|
| This ECMA Standard is based on several originating technologies, the most
| well known being JavaScript (Netscape) and JScript (Microsoft). The
| language was invented by Brendan Eich at Netscape and first appeared in
| that company?s Navigator 2.0 browser. It has appeared in all subsequent
| browsers from Netscape and in all browsers from Microsoft starting with
| Internet Explorer 3.0.

But then again, you never bothered to read *any* specification.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top