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.