«

VK wrote:

>> Richard Cornford wrote:
>> 100% in accordance with the behaviour specified in ECMA 262.
>
> 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

Thomas 'PointedEars' Lahn <> writes:

> 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
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Thomas 'PointedEars' Lahn wrote:
> 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".

VK wrote:

> Thomas 'PointedEars' Lahn wrote:
>> 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

Lasse Reichstein Nielsen wrote:

> Thomas 'PointedEars' Lahn <> writes:
>> 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

> 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.

"VK" <> writes:

> 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
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Thomas 'PointedEars' Lahn <> writes:

> 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
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

> 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...

VK wrote:

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

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