undefined vs. undefined (was: new Array() vs [])
VK
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/3716384d8bfa1b0b>
as an option)
As that is not in relevance to "new Array() vs []" question or to the
array performance, I dared to move it to a new thread.
Gecko takes undefined value strictly as per Book 4, Chapter 3, Song 9
of Books of ECMA
:-)
(Paragraph 4.3.9 of ECMAScript Language Specification, 3rd edition)
:-|
<quote> The undefined value is a primitive value used when a variable
has not been assigned a value. </quote>
As a matter complication JavaScript is the only language I know where
one can write:
var foo = undefined;
which is - strictly speaking - "keep foo but assign it the value that
foo was not assigned and never existed" which is - even more strictly
speaking - totally meaningless.
In case of an elision in an array initializer you *do* assign values to
each and every array member (Mr. Cornford would say something like
"[[Put]] method is called for each evaluation result").
This way
var arr = ['A',,'B']
really means
var arr = ['A',undefined,'B']
with three array members explicetly assigned to the array on the
initialization stage. And each and every *assigned* array member is
reflected as an enumerable object property of the underlaying Object
object. To see the difference (and the real sense of undefined value)
try this:
<script type="text/javascript">
function f(arg) {
for (var p in arg) {
window.alert(arg[p] || 'undefined');
}
window.alert('loops: ' + i);
}
function demo() {
var arr = ['A',,'B'];
arr[100] = 'C';
f(arr);
}
window.onload = demo;
</script>
arr[1] member gets an explicit assignment; thus then you treat your
array as an Object type, you see it as property "1" with value
undefined.
After arr[100] = 'C'; you're getting 96 members gap to the next defined
value. But arr[3]...arr[99] never participated in any assignment
operations. They are undefined and existing only in the abstract array
continuum space. Therefore they are not reflected as object properties.
Richard Cornford
> (see the post by ASM in the original thread; can be seen at
>
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/3
716384d8bfa1b0b>
> as an option)
>
> As that is not in relevance to "new Array() vs []" question
> or to the array performance, I dared to move it to a new thread.
Or was it because you might avoid looking as much of a fool if you post
this without a context as you would if you did.
> Gecko takes undefined value strictly as per Book 4, Chapter 3,
> Song 9 of Books of ECMA
> :-)
> (Paragraph 4.3.9 of ECMAScript Language Specification, 3rd edition)
> :-|
The numbering of clauses in ECMA 262 has no relationship to paragraphs,
books, chapters or songs.
> <quote> The undefined value is a primitive value used when
> a variable has not been assigned a value. </quote>
And section 10.1.3 explains the assignment of the undefined value to
instantiated variables. And no observable behaviour of _any_ ECMAScript
implementations contradicts section 10.1.3.
> As a matter complication JavaScript is the only language I
> know where one can write:
> var foo = undefined;
The only thing specific to javascript in that statement is using - var -
to declare a variable (and that may not be unique to javascript).
> which is - strictly speaking - "keep foo but assign it the
> value that foo was not assigned and never existed"
Nonsense. The meaning of that statement is in two parts:-
1. During 'variable instantiation' for the execution context; create
a property named 'foo' on the Activation/Variable object for the
execution context (with a DontDelete attribute) and assign the
Undefined value to it.
2. When execution of the code arrives at the assignment expression:
The left-hand side is evaluated (into a Reference type with
the Activation/Variable object as its 'base' property and 'foo'
as its property name). The right hand side is evaluated to a
value:
The Identifier 'undefined' is resolved against the scope chain
to give a Reference type. ECMAScript Edition 3 introduced a
property of the global object with the name 'undefined' set to
the Undefined value so the Reference type will likely have the
global object as its 'base' property. In pre-ECMAScript edition
3 environments that do not have a global 'undefined' property
as an extension, or no programmer defined alternative has been
created, the 'base' property of the Reference type will be null.
The resulting Reference type is then passed to the internal
GetValue function to recover a value (and exception will be
thrown at this point if the Reference type has a null 'base'
property).
The value of the right hand side is then used with the Reference
type from the left hand side in order to assign the value. The
property of the Activation/Variable object named 'foo' is
assigned the value of the right hand side (assuming no exception
was thrown while recovering the value from the Identifier
- undefined -).
> which is - even more strictly
> speaking - totally meaningless.
What you wrote is meaningless, but that is just a manifestation of your
not understanding javascript. The actual statement is doing nor more
than (and no less than) evaluating a variable (undefined) and assigning
its value to another variable (foo).
> In case of an elision in an array initializer you *do* assign
> values to each and every array member
Rubbish. The evaluation of an elision will not result in any value being
assigned to any element of an array except its - length - property in
the event that the elision is not followed by an AssignmentExpression.
> (Mr. Cornford would say something like
> "[[Put]] method is called for each evaluation result").
I am unlikely to say something that is utterly false.
> This way
> var arr = ['A',,'B']
> really means
> var arr = ['A',undefined,'B']
No it does not. It is closer to:-
var arr = new Array;
arr[0] = 'A';;
arr[2] = 'B';
> with three array members explicetly assigned to the array
> on the initialization stage.
If that did happen it would be an implementation bug (as was the case in
the firefox/Mozilla versions discussed in the other thread).
> And each and every *assigned* array member is
> reflected as an enumerable object property of the
> underlaying Object object. To see the difference (and the
> real sense of undefined value) try this:
>
> <script type="text/javascript">
> function f(arg) {
> for (var p in arg) {
> window.alert(arg[p] || 'undefined');
> }
> window.alert('loops: ' + i);
> }
>
> function demo() {
> var arr = ['A',,'B'];
> arr[100] = 'C';
> f(arr);
> }
>
> window.onload = demo;
> </script>
>
> arr[1] member gets an explicit assignment;
If it does then that would be in implementation bug.
> thus then you treat your array as an Object type,
There is no meaningful sense in which anyone could treat an array as not
being an object type, as it always is of that type.
> you see it as property "1" with value
> undefined.
> After arr[100] = 'C'; you're getting 96 members gap to
> the next defined value. But arr[3]...arr[99] never participated
> in any assignment operations. They are undefined and existing
> only in the abstract array continuum space. Therefore they are
> not reflected as object properties.
So, apart from demonstrating your ability to shamelessly post material
that is 100% factually false (that is; your assertions here about what
ECMA 262 3rd Ed. says and means are the opposite of reality) what is
your point?
At lest the other thread came to the (correct) conclusion that the
firefox/Mozilla behaviour described was an implementation bug.
Richard.
VK
Richard Cornford wrote:
> At lest the other thread came to the (correct) conclusion that the
> firefox/Mozilla behaviour described was an implementation bug.
I will definitely clarify this on Bugzilla and post the response here.
Nevertheless in the matter of JavaScript engine behavior Mozilla is
most likely to be by ECMAScript standard, at least it was since the
beginning and until now.
Before Mozilla team will give an answer, I say my humble opinion on
this matter: it is another side effect of specification bug ;-)
allowing undefined value to be *assigned* and being involved in some
internal *assignment* operations.
I'm glad that I don't need to make a choice how to treat a property
with explicetly assigned value "this property doesn't exist and never
existed".
As a property with such value? (Gecko)
As non-existing property? (IE and Co)
Truthfully I would feel like to drop a coin, and then go to Switzerland
to hit some dumb heads :-)
Richard Cornford
> Richard Cornford wrote:
>> At lest the other thread came to the (correct) conclusion
>> that the firefox/Mozilla behaviour described was an
>> implementation bug.
>
> I will definitely clarify this on Bugzilla and post the
> response here.
Why, when the tread you decided your post should not be added to already
includes the bugzilla report (with its confirmation that it was a bug)?
> Nevertheless in the matter of JavaScript engine behavior
> Mozilla is most likely to be by ECMAScript standard, at
> least it was since the beginning and until now.
Not really. There are very few actual implementation bugs and those few
are pretty evenly distributed.
> Before Mozilla team will give an answer,
Too late then.
> I say my humble opinion on this matter:
Nobody cares what your opinion is.
> it is another side effect of specification bug ;-)
Half-wit.
> allowing undefined value to be *assigned* and being
> involved in some internal *assignment* operations.
Your inability to understand javascript is well established by now, but
as a consistent, logical system with its behaviour fully specified (so
completely understandable and predictable) that inability is a
reflection only on your mental processes and nothing else.
> I'm glad that I don't need to make a choice how to
> treat a property with explicetly assigned value "this
> property doesn't exist and never existed".
That is the sort of nonsense that makes it clear why your opi9nion is of
no value.
> As a property with such value? (Gecko)
> As non-existing property? (IE and Co)
>
> Truthfully I would feel like to drop a coin, and then go to
> Switzerland to hit some dumb heads :-)
The specification is clear on the subject, Mozilla/Gecko is (or was)
wrong and will be fixed so that it complies with the specification.
Richard.
John G Harris
<school...@yahoo.com> writes
<snip>
>As a matter complication JavaScript is the only language I know where
>one can write:
> var foo = undefined;
>which is - strictly speaking - "keep foo but assign it the value that
>foo was not assigned and never existed" which is - even more strictly
>speaking - totally meaningless.
<snip>
'Undefined' is a short way of saying the value it had when it was
created and hadn't yet been assigned any different value. Assigning
'undefined' (a keyword) is a way of restoring it to the initial state.
I'm amazed that VK has the nerve to complain about a slightly awkward
use of English.
John
--
John Harris
Richard Cornford
<snip>
> ... . Assigning 'undefined' (a keyword)
Not a keyword, just an Identifier, and one that is likely to be resolved
as the specification defined (ECMA 262 3re Ed. Section 15.1.1.3)
property of the global object, which explicitly has the Undefined value.
As it is not a keyword any function, formal parameter or variable could
be named 'undefined' (along with any custom object property) and so
replace or mask the global object's property. (The global 'undefined'
property has the DontDelete and DontEnum attributes but it is not
ReadOnly). Though obviously 'undefined' would be a spectacularly poor
name to be giving to functions/parameters/variables/properties.
<snip>
> I'm amazed that VK has the nerve ...
Ditto.
Richard.
VK
> > response here.
>
> Why, when the tread you decided your post should not be added to already
> includes the bugzilla report (with its confirmation that it was a bug)?
At the moment I was starting this thread the latest post by Cameron
McCormack
<http://groups.google.com/group/comp.lang.javascript/msg/45a87b8f172b03b4>
was not shown yet in my browser. The thread ended up by Rob's post.
I'm gratiful to Cameron McCormack for finding the relevant Bugzilla
filing and for saving my time on that. So indeed it is confirmed to be
a Gecko JavaScript engine bug: see
<https://bugzilla.mozilla.org/show_bug.cgi?id=260106>
So I was wrong and Microsoft was right in this case.
Yet this bug existence (if translated from C++) is layed on the
situation of an "assignment of the value of no assignment" and
indexing troubles after that. Doesn't make myself neither Mozilla right
of course.
Richard Cornford
<snip>
> So I was wrong
<snip>
That was inevitable from the moment you posted. It is just a pity you
waste so much time (that could be better given to more deserving cases)
finding out why you were inevitably wrong. Just understand; you
conception of javascript is largely a fictional product of your own
deranged imagination and has no more than a superficial relationship
with reality. If you would finally accept that truth you might be able
to do something about acquiring a worthwhile understanding of the
subject, or at leas to stop wasting so much of other peoples time by
keeping your lunacy to yourself.
Richard.
scrip...@gmail.com
it looks like there are only morons surrounding you.
Maybe you are too perfect for this world? ;o)
Richard Cornford
What is up, you have something against the propagation of accurate
information?
Richard.
scrip...@gmail.com
Richard Cornford написав:
to talk with person who shows to everyone: "there is only two opinions:
my opinion and wrong opinion".
I believe that you are real JS guru, but sometimes you realy rough with
people. BTW you are not the only man here who love and know JS.
VK
VK wrote:
> So indeed it is confirmed to be
> a Gecko JavaScript engine bug: see
> <https://bugzilla.mozilla.org/show_bug.cgi?id=260106>
> So I was wrong and Microsoft was right in this case.
*IMHO*
After thinking it over again tonight, I see no bug in Mozilla. But I
see a specification bug in the referenced ECMAScript section 11.1.4
which is in turn a reflection of erroneus decision once made to allow
undefined value to be *assigned*.
Quote 1
4.3.9 Undefined Value
The undefined value is a primitive value used
when a variable has not been assigned a value.
Quote 2
8.1 The Undefined Type
The Undefined type has exactly one value, called undefined.
Any variable that has not been assigned a value has
the value undefined.
Quote 3
11.1.4 Array Initialiser, preface
... Elided array elements are not defined.
Quote 4
11.1.4 Array Initialiser, production
(VK: for say [,1,2] array initializer)
...
1. Create a new array as if by the expression new Array().
2. Evaluate Elision; if not present, use the numeric value zero.
3. Call the [[Put]] method of Result(1) with arguments
"length" and Result(2).
4. Return Result(1).
...
Quote 5
8.6.2.2 [[Put]] (P, V)
(VK: referenced on step 3 in the previous quote)
When the [[Put]] method of O is called with property P and value V,
the following steps are taken:
1. Call the [[CanPut]] method of O with name P.
2. If Result(1) is false, return.
3. If O doesn't have a property with name P, go to step 6.
4. Set the value of the property to V. The attributes of the property
are not changed.
5. Return.
6. Create a property with name P, set its value to V and give it empty
attributes.
7. Return.
This way I see a specification bug in 11.1.4 where the preface is in
contradiction with the production. By going by the production, it is
not possible to have "not defined" members in place of elision. There
is an explicit assignment (set) operation involved, therefore we only
can have *members explicetly initialized with undefined value*.
In this respect if we want
arr = [,1,2];
to produce an array that can be treated it as an object with two
properties ("1" and "2", but not "0"): then we also have to request
that
obj = {};
obj.foo = undefined;
would result in an object with no enumerable properties (no <foo>
property).
Technically by the production schema these are totally the same, but no
one seems filing a bug for the later.
That's again: there is a cardinal difference between i) something that
exists and it has explicetly assigned undefined value and ii) something
that doesn't exists anymore or never existed.
Section 11.1.4 requires two opposite things in preface section and in
production section, so it's the programmer's choice what to follow.
Here some code I've made while making my mind together :-) :
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">
var br = '\n';
var p = br + br;
function test1(out) {
out.value = 'Test 1' + p;
// variable <foo> is explicetly initialized
// with undefined value:
var foo = undefined;
// variable <bar> simply doesn't exist
// neither in local nor in global scopes
out.value+= (typeof foo) + br; // "undefined"
out.value+= (typeof bar) + br; // "undefined"
// but later:
try {
out.value+= (foo == 0) + br; // false
out.value+= (bar == 0) + br; // run-time error
}
catch(e) {
out.value+= 'Run-time error: ' + e.message + br;
}
}
function test2(out) {
out.value = 'Test 2' + p;
var obj = new Object();
// property <foo> is explicetly initialized
// with undefined value:
obj.foo = undefined;
// property <bar> simply doesn't exist
// in <obj> object
out.value+= (typeof obj.foo) + br; // "undefined"
out.value+= (typeof obj.bar) + br; // "undefined"
// but only one enumerable property <foo> exists:
for (var prop in obj) {
out.value+= prop + ' = ' + obj[prop] + br;
}
}
function test3(out) {
out.value = 'Test 3' + p;
// initializing array with elision:
var arr = [,1,2];
out.value+= 'length: ' + arr.length + p; // 3
for (var i=0; i<arr.length; i++) {
out.value+= 'arr['+i+'] = ' + arr[i] + br;
}
out.value+= p;
for (var prop in arr) {
out.value+= 'arr.'+prop+' = ' + arr[prop] + br;
}
out.value+= p;
delete arr[0];
for (var prop in arr) {
out.value+= 'arr.'+prop+' = ' + arr[prop] + br;
}
}
</script>
</head
><body
><form method="post" action=""
><textarea name="out" cols="64" rows="16"></textarea
><br
><input type="button" name="b1" value="Test 1"
onClick="test1(this.form.out)"
><input type="button" name="b2" value="Test 2"
onClick="test2(this.form.out)"
><input type="button" name="b3" value="Test 3"
onClick="test3(this.form.out)"
></form
></body
></html>
Richard Cornford
> Richard Cornford напиÑ ав:
>> scrip...@gmail.com wrote:
>>> it looks like there are only morons surrounding you.
>>> Maybe you are too perfect for this world? ;o)
>>
>> What is up, you have something against the propagation
>> of accurate information?
>>
>> Richard.
> I never was against an accurate information. But it is
> not a pleasure to talk with person who shows to
> everyone: "there is only two
> opinions: my opinion and wrong opinion".
Where is the opinion here? VK's original post was 100% the opposite of
the truth and - undefined - is not a keyword in javascript.
> I believe that you are real JS guru,
Anyone who would want to be labelled "guru" should be regarded with
extreme suspicion (with the possible exception of Fakirs and related
Indian mystics).
> but sometimes you realy rough with people.
Rarely without reason.
> BTW you are not the only man here who love and know JS.
Your point?
Richard.
Richard Cornford
> VK wrote:
>> So indeed it is confirmed to be
>> a Gecko JavaScript engine bug: see
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=260106>
>> So I was wrong and Microsoft was right in this case.
>
> *IMHO*
Your opinions are worthless, for reasons that will once again become
clear.
> After thinking it over again tonight,
Don't confuse your mental processes with thinking (at least in the sense
that everyone else uses the term).
> I see no bug in Mozilla.
So where everyone else sees a bug, including the people who wrote the
script engine for Mozilla, you don't see one.
> But I see a specification bug in the referenced
> ECMAScript section 11.1.4 which is in turn a
> reflection of erroneus decision once made to allow
> undefined value to be *assigned*.
>
> Quote 1
> 4.3.9 Undefined Value
> The undefined value is a primitive value used
> when a variable has not been assigned a value.
The mechanism for which ("used when a variable has not been assigned a
value") is laied out in section 10.1.3 under "Variable Instantiation".
> Quote 2
> 8.1 The Undefined Type
> The Undefined type has exactly one value, called undefined.
> Any variable that has not been assigned a value has
> the value undefined.
>
>
> Quote 3
> 11.1.4 Array Initialiser, preface
> ... Elided array elements are not defined.
The distinction between a 'variable', as referred to in section 4.3.9,
and an array element being significant.
> Quote 4
> 11.1.4 Array Initialiser, production
> (VK: for say [,1,2] array initializer)
So the applicable productions would be the production:
ArrayLiteral : [ ElementList , Elison<opt> ]
- including the production:
ElementList: Elision<opt> AssignmentExpression.
> ...
> 1. Create a new array as if by the expression new Array().
> 2. Evaluate Elision; if not present, use the numeric value zero.
This is not the algorithm for - [,1,2] -, it is the algorithm for -
[,,] - and the like. The production:
ArrayLiteral: [ Elision<opt> ]
If you are going to make statements about the interpretation of ECMA 262
you should at lest refer to the relevant sections.
> 3. Call the [[Put]] method of Result(1) with arguments
> "length" and Result(2).
Note that the property name being assigned to here is "lenght".
> 4. Return Result(1).
> ...
>
> Quote 5
> 8.6.2.2 [[Put]] (P, V)
<snip>
The special [[Put]] method of Arrays is defined in section 15.4.5.1 and
differs from the standard object [[Put]] method quoted here.
> This way I see a specification bug in 11.1.4
You read the wrong ArrayLiteral algorithm(s) and use the wrong [[Put]]
method and you see a "specification bug"?
> where the preface is in
> contradiction with the production.
Is that the production you referred to or the applicable productions?
> By going by the production, it is not possible to have
> "not defined" members in place of elision.
You omitted to cover the productions for Elision:-
The production Elision :, is evaluated as follows:
1. Return the numeric value 1.
The production Elision : Elision, is evaluated as follows:
1. Evaluate Elision.
2. Return (Result(1)+1).
So in your cited algorithm, applied to [,,]:-
| 2. Evaluate Elision; if not present, use the numeric value zero.
- the numeric value is going to be two. And then:-
| 3. Call the [[Put]] method of Result(1) with arguments
| "length" and Result(2).
- writes the value 2 to the length property of the array, without
defining, or assigning to, any actual array elements.
So in what sense if it "not possible to have "not defined" members in
place of elision"? Here the length is 2 and the array has no other
defined properties, as a result of two Elisions in the Array literal.
> There is an explicit assignment (set) operation involved,
To the 'length' property.
> therefore we only can have *members explicetly
> initialized with undefined value*.
You have not shown any.
> In this respect if we want
> arr = [,1,2];
> to produce an array that can be treated it as an object
> with two properties ("1" and "2", but not "0"): then
> we also have to request
> that
> obj = {};
> obj.foo = undefined;
> would result in an object with no enumerable properties
> (no <foo> property).
Such has not been demonstrated here. In the case of the array no
explicit assignment is made to a property with the name '0', while in
the case of the object a property named 'foo' has been explicitly
assigned a value.
> Technically by the production schema these are totally
> the same,
Even if they were, and they are not, how would you know? What you
understand of what you read differs significantly from the meaning of
what you read.
> but no one seems filing a bug for the later.
OK. There is a mental processing bug in VK's mind that leaves him
incapable of perceiving reality. You may consider the bug reoprted to
the responsible party.
<snip>
> Section 11.1.4 requires two opposite things in preface
> section and in production section, so it's the
> programmer's choice what to follow.
No contradiction exists. Elision evaluation either only changes the -
length - property of an array or it only offsets the index where the
results of AssignmentExpressions are stored (with consequential effects
on the - length -).
> Here some code I've made while making my mind
> together :-) :
<snip>
LOL
Richard.
Michael Winter
[snip]
> After thinking it over again tonight, I see no bug in Mozilla.
Somehow, I knew you'd write that.
Really VK, why the hell do you post to this group? How can you possibly
think that you are able to assist anyone when you blatantly haven't got
a clue about this language?
> But I see a specification bug in the referenced ECMAScript section
> 11.1.4 ...
You would.
> 4.3.9 Undefined Value
> The undefined value is a primitive value used
> when a variable has not been assigned a value.
Which does not say that such a value may not be assigned to a property.
> 8.1 The Undefined Type
> The Undefined type has exactly one value, called undefined.
> Any variable that has not been assigned a value has
> the value undefined.
Ditto.
> 11.1.4 Array Initialiser, preface
> ... Elided array elements are not defined.
Which means that no property is created for that object where the
elision occurs. The bug in Mozilla is that it does create such a property.
> 11.1.4 Array Initialiser, production
> (VK: for say [,1,2] array initializer)
> ...
> 1. Create a new array as if by the expression new Array().
> 2. Evaluate Elision; if not present, use the numeric value zero.
> 3. Call the [[Put]] method of Result(1) with arguments
> "length" and Result(2).
> 4. Return Result(1).
> ...
You've quoted the wrong production for the proposed ArrayLiteral. The
correct /series/ of productions would be:
The production ArrayLiteral : [ ElementList ] is evaluated as
follows:
1. Evaluate ElementList.
2. Return Result(1).
The production ElementList : ElementList , Elision(opt)
AssignmentExpression is evaluated as follows:
1. Evaluate ElementList.
2. Evaluate Elision; if not present, use the numeric value
zero.
3. Evaluate AssignmentExpression.
4. Call GetValue(Result(3)).
5. Call the [[Get]] method of Result(1) with argument
"length".
6. Call the [[Put]] method of Result(1) with arguments
(Result(2)+Result(5)) and Result(4).
7. Return Result(1)
(where the Elision is omitted) and:
The production ElementList : Elision(opt) AssignmentExpression
is evaluated as follows:
1. Create a new array as if by the expression new Array().
2. Evaluate Elision; if not present, use the numeric value
zero.
3. Evaluate AssignmentExpression.
4. Call GetValue(Result(3)).
5. Call the [[Put]] method of Result(1) with arguments
Result(2) and Result(4).
6. Return Result(1)
(where Elision is evaluated and returns a value of 1).
Following those steps, a new Array object is created, and the values 1
and 2 are assigned to properties '1' and '2', respectively. No property
'0' is created, therefore it cannot be enumerated.
> 8.6.2.2 [[Put]] (P, V)
Moron. That's the wrong [[Put]] method.
[snip]
> This way I see a specification bug in 11.1.4 where the preface is in
> contradiction with the production.
Perhaps if you knew how to read the specification, you wouldn't be so
confused.
> By going by the production, it is not possible to have "not defined"
> members in place of elision.
Yes, it is. An Elision that occurs at the start, or amongst other
AssignmentExpression productions, determines what property name is used
when assigning the result of evaluating each AssignmentExpression. A
trailing Elision affects the final value assigned to the length property
of the Array object. An Elision production does not cause an assignment
by itself:
The production Elision : , is evaluated as follows:
1. Return the numeric value 1.
The production Elision : Elision , is evaluated as follows:
1. Evaluate Elision.
2. Return (Result(1)+1).
except where it is the only production to be evaluated in the
ArrayLiteral, in which case only the length property is affected.
> There is an explicit assignment (set) operation involved, therefore
> we only can have *members explicetly initialized with undefined
> value*.
Give up before you give yourself a headache.
[snip]
Mike
VK
> Really VK, why the hell do you post to this group? How can you possibly
> think that you are able to assist anyone when you blatantly haven't got
> a clue about this language?
You know what, Dear Sir, you've got on my *really* bad day today. So
right why would not address both of above questions to yourselve as the
most applicable person around here?
<snip>
> Elision that occurs at the start, or amongst other
> AssignmentExpression productions, determines what property name is used
> when assigning the result of evaluating each AssignmentExpression.
Moron, you're mixing again hell out of an object property production
and an array member production (besides reading and quoting specs like
a drunk vagabond). In JavaScript array (viewed from the objective point
of view) *index* becomes property name, elision provides the *value*
for the that property.
var arr = [1,,2];
in terms of object/property/value is
var obj = {'0':1, '1':undefined, '2':2}
and
var arr = [,1,2];
in terms of object/property/value is
var obj = {'0':undefined, '1':undefined, '2':2}
with some conclusions to make about this "bug" (if you are able to make
any independent conclusions).
P.S. I'm almost sorry to start both this one and <this> discussions.
The inevitable obligation to mit over and over again the same narrow
set of morons insured that they know everything possible about
JavaScript (and whatever they don't is either wrong or useless) - this
obligation takes sometimes too much of energy to spent w/o many
benefits.
Richard Cornford
> Michael Winter wrote:
>> Really VK, why the hell do you post to this group? How can you
>> possibly think that you are able to assist anyone when you blatantly
>> haven't got a clue about this language?
>
> You know what, Dear Sir, you've got on my *really* bad day today.
And in English that would be?
> So right why would not address both of above questions to yourselve
> as the most applicable person around here?
More gibberish.
> <snip>
>> Elision that occurs at the start, or amongst other
>> AssignmentExpression productions, determines what property
>> name is used when assigning the result of evaluating each
>> AssignmentExpression.
>
> Moron, you're mixing again hell out of an object property production
> and an array member production (besides reading and quoting specs
> like a drunk vagabond).
Then you don't see that Mike is 100% on the money?
> In JavaScript array
Remember that when you asserted that you were a "world expert" on
javascript arrays you immediately had to take that back and make out it
was intended to be humorous in order to avoid looking a complete fool.
> (viewed from the objective point of view)
Can someone as deluded as you view anything from an objective point of
view?
> *index* becomes property name, elision provides the *value*
> for the that property.
No. Elision on its own only adjusts the - length - property, and
Elision followed by AssignmentExpression determines the array index
used to store the value of the assignment expression:-
The production
ElementList : ElementList , Elisionopt AssignmentExpression
is evaluated as follows:
1. Evaluate ElementList.
2. Evaluate Elision; if not present, use the numeric value zero.
Evaluate Elision gives a number equivilnet ot the number of elisions,
else zero is used if there are no Elisions.
3. Evaluate AssignmentExpression.
Evaluate AssignmentExpression (giving Result(3) ) determines the value
of the assignment expression if it is not a Reference type.
4. Call GetValue(Result(3)).
Call GetValue(Result(3)) turns Reference types into actual values, but
does not alter non-Reference type values.
5. Call the [[Get]] method of Result(1) with argument "length".
Result(5) is the length of the array following the evaluation of
ElementList in step one.
6. Call the [[Put]] method of Result(1) with arguments
(Result(2)+Result(5)) and Result(4).
Result(1) is the array, (Result(2)+Result(5)) is a number determined by
the number of Elisions plus the current length of the array and is used
as the property name here, and Result(4) is the value of the
AssignmentExpression.
7. Return Result(1)
There is no question of the elision providing any values for array
elements, just influencing the 'array index' property named used and
consequently the - length - property of the array. (and the same goes
for all the other productions)
> var arr = [1,,2];
> in terms of object/property/value is
> var obj = {'0':1, '1':undefined, '2':2}
No, the equivalent in terms of object Initialisers is:-
var obj = {'0':1, '2':2}
- no value will be assigned to any property with the name '1'.
> and
> var arr = [,1,2];
> in terms of object/property/value is
> var obj = {'0':undefined, '1':undefined, '2':2}
No, the equivalent in terms of object Initialisers is:-
var obj = {'1':1, '2':2}
- no value will be assigned to any property with the name '0'.
> with some conclusions to make about this "bug" (if you are
> able to make any independent conclusions).
The conclusion about the bug was made some time ago: JavaScript(tm) 1.5
has an implementation bug that will be fixed.
> P.S. I'm almost sorry to start both this one and <this>
> discussions.
You have made yourself look a fool in public again and you are only
almost sorry? It is no wonder that you manage to make yourself look
such a fool with such relentless frequency.
> The inevitable obligation to mit over and over
> again the same narrow set of morons insured that they know
> everything possible about JavaScript (and whatever they
> don't is either wrong or useless) - this obligation takes
> sometimes too much of energy to spent w/o many benefits.
When you cite the wrong algorithms, misinterpret those algorithms, draw
false conclusions and fail to comprehend corrections any time wasting
that is going on is entirely down to you.
Yes the entire exercise has no benefit for you, but that is because you
are incapable of seeing that you are wrong when you are wrong (at least
without having the truth repeatedly shoved down your throat, and often
not even then).
Richard.
Michael Winter
[snip]
> You know what, Dear Sir, you've got on my *really* bad day today.
LOL
[snip]
>> [An] Elision that occurs at the start, or amongst other
>> AssignmentExpression productions, determines what property name is
>> used when assigning the result of evaluating each
>> AssignmentExpression.
>
> Moron, you're mixing again hell out of an object property production
> and an array member production (besides reading and quoting specs
> like a drunk vagabond).
Even you should be able to see that what I quoted came only from section
11.1.4.
It's not my fault that you can't understand the formal grammar used in
the specification.
> In JavaScript array (viewed from the objective point of view) *index*
> becomes property name,
And where do you think the index comes from?
If you walk, step-by-step, through the algorithm of each production I
posted, you can see quite clearly how elisions affect array creation. If
you actually try that, don't assume that what happens is what you think
is supposed to happen (because you idea of things is simply wrong), just
do it as the algorithm specifies.
> elision provides the *value* for the that property.
If you care to think about that statement, you should see that it is
absolutely false.
An Elision production evaluates to a number. On its own, 1:
The production Elision : , is evaluated as follows:
1. Return the numeric value 1.
Where multiple elisions occur, they are added:
The production Elision : Elision , is evaluated as follows:
1. Evaluate Elision.
2. Return (Result(1)+1).
The only property value that elisions affect is the length property,
either directly for trailing elisions, or indirectly by altering the
value passed to the internal (Array) [[Put]] method when assigning the
value of an evaluated AssignmentExpression production.
> var arr = [1,,2];
> in terms of object/property/value is
> var obj = {'0':1, '1':undefined, '2':2}
No, it isn't.
> and
> var arr = [,1,2];
> in terms of object/property/value is
> var obj = {'0':undefined, '1':undefined, '2':2}
Definitely not!
[snip]
Mike
VK
>
> LOL
I'm much better now. I should remember that going beyond the netiquette
restores your stamina really well some times. ;-) The only problem is
do not get too used to such remedie: like some of my opponents did.
What is the difference between a documentation frick and a real
language specialist (excluding myself from either group)? A
documentation frick will quote, and quote... and quote. That is the
only thing you'll possibly get on your questions. However you're
asking, the thinking process of your opponent is being blocked: because
on each situation he has a relevant or not so relevant quote from the
book.
Just go by your road. I've got my monthly limit of quotes from the
Books of ECMA, no more for a while.
btw don't forget to file another "bug" then: Mozilla doesn't treat
properly array members initialized with undefined value.
<script type="text/javascript">
var prop = null;
var arr1 = [1,,,2]
var arr2 = [1,undefined,undefined,2]
for (var prop in arr1) {
alert(prop + ' = ' + arr1[prop]);
}
for (var prop in arr2) {
alert(prop + ' = ' + arr2[prop]);
}
</script>
Richard Cornford
>>> You know what, Dear Sir, you've got on my *really* bad
>> day today.
>>
>> LOL
>
> I'm much better now. I should remember that going beyond the
> netiquette restores your stamina really well some times. ;-) The only
> problem is do not get too used to such remedie: like some of my
> opponents did.
>
> What is the difference between a documentation frick
> and a real language specialist (excluding myself from
> either group)? A documentation frick will quote, and
> quote... and quote.
You started the quoting. You quoted algorithms and text, and then you
made false assertions (of non-existent contradictions), apparently based
on misinterpreting the wrong algorithms.
> That is the
> only thing you'll possibly get on your questions.
What was your question? It seems to me that you made a series of false
statements, declared yourself wrong, recanted and declared everything
else wrong and now are unwilling to accept that your first declaration
of culpability was the inevitably correct one.
> However you're asking, the thinking process of your
> opponent is being blocked: because on each situation
> he has a relevant or not so relevant quote from the book.
You asserted that there was a contradiction in the specification and you
asserted that the algorithms stated that an elision would assign an
'array index' property to an array. How do you expect to be shown that
no contraditi9on exists and no 'array index' properties are assigned in
the algorithms than to be shown, and re-shown the actual text stating
the opposite of what you asserted it said?
Of course rather than admitting (or probably even recognising) that you
were wrong yet again, you would rather suggest that the style of
argument you initially introduced is only significant when it is you
(mis)interpreting the text.
> Just go by your road. I've got my monthly limit of quotes
> from the Books of ECMA, no more for a while.
>
> btw don't forget to file another "bug" then: Mozilla
> doesn't treat properly array members initialized with
> undefined value.
"Mozilla doesn't treat properly array members initialized with undefined
value" what, how? In what way does Mozilla not "treat" "property array
members initalized with undeifned"? Indeed what would Mozilla have to do
in order to 'treat' one? If you are going to write this nonsense the
least you could do is carry your sentences through to completion (or is
you though process so disjointed that could not achieve even that).
> <script type="text/javascript">
> var prop = null;
>
> var arr1 = [1,,,2]
> var arr2 = [1,undefined,undefined,2]
>
> for (var prop in arr1) {
> alert(prop + ' = ' + arr1[prop]);
> }
>
> for (var prop in arr2) {
> alert(prop + ' = ' + arr2[prop]);
> }
> </script>
Given that the known (and reported) bug explains the outcome for -
aray1 - and the outcome for - array2 - is entirely in accordance with
the specification, where is this 'another "bug"' you allude to?
It is not, by any chance, another figment of your deranged imagination
is it?
Richard.
Michael Winter
[snip]
> What is the difference between a documentation frick and a real
> language specialist (excluding myself from either group)?
I don't know. What is a frick, first of all? Beyond it being a
derogative term (I presume), I have no idea what it means.
> A documentation frick will quote, and quote... and quote.
So, you first quote from the specification to try and make your point,
but there's something wrong when someone else does it?
> That is the only thing you'll possibly get on your questions.
I should think that the quoted material should be quite self-explanatory
for anyone familiar with programming. Explaining the sequence of steps
for the entire literal wouldn't have been difficult, but it would have
made for an awfully long post.
> However you're asking, the thinking process of your opponent is being
> blocked: ...
And the same can be said of you: no matter how hard /anyone/ tries,
attempting to get you to realise your mistakes is like trying to get
blood from a stone. But what hope is there for us? You have some
unshakable belief that you're right: even though the Mozilla development
team realise their mistake, you still believe otherwise.
> Just go by your road. I've got my monthly limit of quotes from the
> Books of ECMA, no more for a while.
That's quite convenient.
> btw don't forget to file another "bug" then: Mozilla doesn't treat
> properly array members initialized with undefined value.
Yes, it does. Good grief...
With a literal like:
[,]
there are no defined array index properties ('0', '1', '2', etc.), but
the length property value is 1 (due to the presence of the elision).
With a literal like:
[undefined]
there is one property, '0', with the value undefined, and a length
property value of 1.
Mozilla gets the former wrong, and the latter right. MSIE gets the
former right, and the latter wrong. Opera gets both right (at some point
after 7.0x - I don't have all versions installed at the moment).
Mike
John G Harris
<school...@yahoo.com> writes
<snip>
> var arr = [1,,2];
>in terms of object/property/value is
> var obj = {'0':1, '1':undefined, '2':2}
<snip>
obj has no property named '1'.
In any standard you can't assume that "not defined" means the same as
"undefined", especially when "undefined" is declared to be the name of
something in the language.
John
--
John Harris
VK
> Mozilla gets the former wrong, and the latter right. MSIE gets the
> former right, and the latter wrong. Opera gets both right (at some point
> after 7.0x - I don't have all versions installed at the moment).
You're funny guys... Both of you in this particular case are a perfect
sample of what happens when the thinking process is the result of
regulations reading (and not when the regulation reading is the result
of the thinking process).
The ECMAScript Language Specification is not a *language*
specification, despite on what its name implies. It is the *engine*
specification. This is a set of in/out block-schemas so anyone could
produce uniformly working script engines.
This way these specs may be (and are) a great source for "hacking"
JavaScript - thus using not so obvious algorithms based on knowledge of
the internal processes - if case when the internal processing
corresponds to the spelled one.
At the same time it is a very dangerous source if taken as stay-alone
only. Internal processes are not the same as higher level programming
entities and abstractions these entities are based on.
In the application to the discussed problem, *prior* any Books of ECMA
reading and quoting it is absolutely necessary to understand what is
object, object property, array, array space (continuum), array member
and undefined entity. It is necessary to understand not "what they are
in JavaScript", but what they are in the programming per se.
<undefined> value means that the entity you tried to access doesn't
exists in the current execution context. Technically it means that this
entity never was initialized: "it has never seen the assignment sign
(=) from its right". Wherever whenever we had an assignment then we
don't have an undefined entity there anymore. Rather simple, is not it?
Yet there can be an unforeseen confusion in JavaScript due to the
erroneous decision to let undefined value to be *assigned*: in
violation of the very nature of undefined and in violation of any
programming logic.
But if one learned well what does <undefined> mean (see the definition
atop), she will never be confused. She will just smile over some
passages in the ECMAScript specs.
(see full HTML page with samples at the bottom of this post)
1)
var arr = ['A',,'C'];
This construct creates an array with tree members (indicies 0,1,2) and
corresponding values 'A', undefined, 'B'
2)
var arr = ['A',undefined,'B'];
This construct is nothing but full version of the shortcut 1)
3)
var arr = new Array(3);
arr[0] = 'A';
arr[1] = undefined;
arr[2] = 'B';
This construct is a full functional equivalent of 1) and 2) but all
assignments are moved out of the initializer to make them more obvious.
Now let's us treat our arrays as basic objects and see how many
properties we've got in each case:
for (var prop in arr) {
window.alert(prop + '=' + arr[prop]);
}
Withing the given <undefined> definition Firefox is the only one
(compared to Opera and IE) acting properly in each case. Opera and IE
are acting wrongly - and more over differently of each other.
arr[1] *is* defined in all three cases - but it contains undefined
value. That is the core glitch in the specs, because there is no
equality between an initialized variable holding undefined value
(arr[1]) and a non-initialized variable (say arr[1001]).
If array member ever was initialized, it does stay initialized, no
matter what assignments you make to it. The one who still remembers
what does <undefined> means in the programming will also *never* expect
that
arr[2] = undefined; // just another assignment
will be *equal* to
delete arr[2]; // send identifier:value pair to the non-existence
<html>
<head>
<title>undefined</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">
var br = '\n';
var p = br + br;
function demo(out) {
var arr1 = ['A',,'C'];
var arr2 = ['A',undefined,'C'];
var arr3 = new Array(3);
arr3[0] = 'A';
arr3[1] = undefined;
arr3[2] = 'B';
var arr4 = ['A','B','C'];
// Demo 1
out.value = "arr1 = ['A',,'C'];" + p;
out.value+= 'arr1.length=' + arr1.length + br;
out.value+= 'arr1 as basic object, properties:' + br;
for (prop in arr1) {
out.value+= 'arr1.' + prop + '=' + arr1[prop] + br;
}
out.value+= p;
// Demo 2
out.value+= "arr2 = ['A',undefined,'C'];" + p;
out.value+= 'arr2.length=' + arr2.length + br;
out.value+= 'arr2 as basic object, properties:' + br;
for (prop in arr2) {
out.value+= 'arr2.' + prop + '=' + arr2[prop] + br;
}
out.value+= p;
// Demo 3
out.value+= "arr3 = new Array(3);" + br
+ " arr[0] = 'A';" + br
+ " arr[1] = undefined;" + br
+ " arr[2] = 'B';" + br;
out.value+= 'arr3.length=' + arr3.length + br;
out.value+= 'arr3 as basic object, properties:' + br;
for (prop in arr3) {
out.value+= 'arr3.' + prop + '=' + arr3[prop] + br;
}
out.value+= p;
// Demo 4
out.value+= "var arr4 = ['A','B','C'];" + br;
out.value+= 'arr4.length=' + arr4.length + br;
out.value+= 'arr4 as basic object, properties:' + br;
for (prop in arr4) {
out.value+= 'arr4.' + prop + '=' + arr4[prop] + br;
}
out.value+= p;
arr4[1] = undefined;
out.value+= "arr4[1] = undefined;" + br;
delete arr4[2];
out.value+= "delete arr4[2];" + br;
out.value+= 'arr4.length=' + arr4.length + br;
out.value+= 'arr4 as basic object, properties:' + br;
for (prop in arr4) {
out.value+= 'arr4.' + prop + '=' + arr4[prop] + br;
}
}
</script>
</head
><body
><form method="post" action=""
><textarea name="output" cols="64" rows="16"></textarea
><br
><input type="button" name="b1" value=" Demo "
onclick="demo(this.form.output)"
></form
></body
></html>
Richard Cornford
VK wrote:
> Michael Winter wrote:
> > Mozilla gets the former wrong, and the latter right. MSIE gets the
> > former right, and the latter wrong. Opera gets both right (at some point
> > after 7.0x - I don't have all versions installed at the moment).
>
> You're funny guys... Both of you in this particular case are a perfect
> sample of what happens when the thinking process is the result of
> regulations reading (and not when the regulation reading is the result
> of the thinking process).
If you are an example of "when the regulation reading is the result of
the thinking process" (which sounds very like a description of someone
perceiving what they want to read instead of what actually is written)
then the former has all the advantges.
> The ECMAScript Language Specification is not a *language*
> specification, despite on what its name implies.
And VK is not a rational human being.
> It is the *engine* specification.
> This is a set of in/out block-schemas so anyone could
> produce uniformly working script engines.
The intention is certainly to facilitate the production of consistent
implementations. That is why when their implementations differ from the
specification the authors admit that they have a bug (and some even fix
them).
> This way these specs may be (and are) a great source for
> "hacking" JavaScript - thus using not so obvious algorithms
> based on knowledge of the internal processes - if case when
> the internal processing corresponds to the spelled one.
> At the same time it is a very dangerous source if taken as
> stay-alone only. Internal processes are not the same as higher
> level programming entities and abstractions these entities are
> based on.
How would you know? If anything is clear from the nonsense you post,
and especially the code you write, programming is an area unknown to
you.
> In the application to the discussed problem, *prior* any Books of ECMA
> reading and quoting it is absolutely necessary to understand what is
> object, object property, array, array space (continuum), array member
> and undefined entity.
> It is necessary to understand not "what they are
> in JavaScript", but what they are in the programming per se.
So that you can convince yourself that something as simple as a value
has some sort of mystical significance and magical properties?
When you are giving advice on how people should best go abut
understanding javascript you should remember that you do not understand
it yourself. While others write code knowing exactly what it will do
you write sequences of mystical incantations an then complain that what
they actually do is not what you expect them to do.
The only post in this thread in which you have not been absolutely
wrong is the one where you admitted to being wrong, and you recanted
that. Everyone knows you are wrong and you are just making yourself
look more of a fool dragging this fantasy of yours out.
> <undefined> value means that the entity you tried to access
> doesn't exists in the current execution context.
Not in javascript. In javascript Undefined is a single value of a
single type, exactly like Null is a single value of a single type.
> Technically
How would you know? This technology is clearly beyond you.
> it means that this entity never was initialized:
> "it has never seen the assignment sign
> (=) from its right".
Then it would not be possible to assign an undefined value. While in
reality it is extremely easy to assign an undefined value.
> Wherever whenever we had an assignment then we
> don't have an undefined entity there anymore.
What is an "undefined entity" in relation to javascript?
> Rather simple, is not it?
The reality is relatively simple, just beyond you.
> Yet there can be an unforeseen confusion in JavaScript due to the
> erroneous decision to let undefined value to be *assigned*:
If you go off into your fantasy world where an undefined value equates
to something having never had a value explicitly assigned it that might
seem erroneous. If you stick with the simple understanding that
undefined is a value that is used under particular circumstances (as
the default return value from a function call. as the return value from
a [[Get]] where the property name does not exist on the object, as the
initial value of variable when instantiated, etc.) being able to assign
it is not only reasonable but inevitable.
> in
> violation of the very nature of undefined and in violation of any
> programming logic.
No, it is just in violation of whatever passes for logic in your case.
As the undefined value is just a value it should be possible to assign
it.
> But if one learned well what does <undefined> mean (see the
> definition atop),
You mean you decided a fantasy was preferable to the reality that you
cannot cope with.
> she will never be confused. She will just smile
> over some passages in the ECMAScript specs.
By which you mean that you will ignore the truth and maintain a fantasy
even though you cannot demonstrate any substance to your fantasy.
> (see full HTML page with samples at the bottom of this post)
You still like posting code without ever stating what it is that code
is supposed to be demonstration, and how the output it produces
actually demonstrated whatever it is.
> 1)
> var arr = ['A',,'C'];
> This construct creates an array with tree members (indicies 0,1,2) and
> corresponding values 'A', undefined, 'B'
Only in the presence of an implementation bug.
> 2)
> var arr = ['A',undefined,'B'];
> This construct is nothing but full version of the shortcut 1)
Nonsense, it follows completely different production rules, as the -
undefined - used there is an Identifier referring to a global variable
and so qualifies as an Assignment Expression.
> 3)
> var arr = new Array(3);
> arr[0] = 'A';
> arr[1] = undefined;
> arr[2] = 'B';
> This construct is a full functional equivalent of 1) and 2) but all
> assignments are moved out of the initializer to make them more
> obvious.
The equivalent of 2), but not 1).
> Now let's us treat our arrays as basic objects and see how many
> properties we've got in each case:
> for (var prop in arr) {
> window.alert(prop + '=' + arr[prop]);
> }
>
> Withing the given <undefined> definition Firefox is the only
> one (compared to Opera and IE) acting properly in each case.
> Opera and IE are acting wrongly - and more over differently of
> each other.
This is a definition of "wrong" along the lines of "differs from my
fantasy"? The formal specification defines what would be right, and so
what would be "wrong".
> arr[1] *is* defined in all three cases - but it contains undefined
> value.
No it is not.
> That is the core glitch in the specs, because there is no
> equality between an initialized variable holding undefined value
> (arr[1]) and a non-initialized variable (say arr[1001]).
Retreating a value for a non-existent property of an object returns the
undefined value, so in the sense that both evaluate to the same value
they are equivalent. In terms of enumeration and the object's -
hasOwnProperty - methods they differ.
> If array member ever was initialized, it does stay initialized, no
> matter what assignments you make to it. The one who still
> remembers what does <undefined> means in the programming
> will also *never* expect that
The one who makes it up off the top of his head will never expect that.
The people who understand what a value is will not have any problems.
> arr[2] = undefined; // just another assignment
> will be *equal* to
> delete arr[2]; // send identifier:value pair to the non-existence
Delete removes the property from an object, it is nowhere near
equivalent from assigning undefined. Removing a property form an object
may stop it masking a property on its prototype, while assigning
undefined will never do that.
Richard.
VK
Richard Cornford wrote:
> ... go abut ...
A typo or a hit check? If the latter then I'm not French Canadian
(though a nice try :-).
Ray
> I never was against an accurate information. But it is not a pleasure
> to talk with person who shows to everyone: "there is only two opinions:
> my opinion and wrong opinion".
I find Richard's posts to be educative and informational. Sometimes I
learn a lot about the innards of JavaScript just by looking at his
replies to VK's ramblings :)
> I believe that you are real JS guru, but sometimes you realy rough with
> people. BTW you are not the only man here who love and know JS.
And... ? Rough with who? I posted a few questions and when he answers,
one can be reasonably confident that it is a _correct_
answer--apparently Richard has devoted time and energy to understand
this technology.
Michael Winter
[snip]
> You're funny guys...
I'll avoid making a retort.
> Both of you in this particular case are a perfect sample of what
> happens when the thinking process is the result of regulations
> reading ...
What makes you think that only Richard and I think you're wrong?
The Opera developers think you're wrong because they once implemented
elisions incorrectly, but have since corrected that implementation.
The Microsoft developers think that you're wrong (not usually a sterling
endorsement, I know).
The Mozilla developers think that you're wrong because they acknowledged
the bug.
I should think that every regular poster in this group thinks that
you're wrong, otherwise I would hope that they'd correct myself,
Richard, or (more recently) John Harris.
As usual, you find yourself alone, yet you're either too stubborn to
admit your mistake, or too stupid to recognise it.
> The ECMAScript Language Specification is not a *language*
> specification, despite on what its name implies.
Right... So, the grammar productions don't specify the syntax for
language constructs, then?
> It is the *engine* specification.
You think it's unreasonable for a language to specify precisely how its
features should behave?
[snip]
> This way these specs may be (and are) a great source for "hacking"
> JavaScript ...
It's got nothing to do with hacking any implementation. The ECMAScript
specification describes observable behaviour: the interpretation of a
given token sequence should produce a predictable result.
Vendor-specific documentation is less precise, but seldom significantly
different (conflicts tend to lie in built-in method descriptions,
especially Array.prototype.split and String.prototype.replace).
> At the same time it is a very dangerous source if taken as stay-alone
> only.
Who, other than yourself, is ignoring practical evidence? You seem to be
basing your decision on a combination of the behaviour of one browser
that suffers from a known (and acknowledged) bug, and your own
misconceptions.
[snip]
> ... Books of ECMA ...
I can't speak for anyone else, but every time you write "Books of ECMA",
or use any similar phrase, you just look like a nut to me.
> it is absolutely necessary to understand what is object, object
> property, array, array space (continuum), array member and undefined
> entity. It is necessary to understand not "what they are in
> JavaScript", but what they are in the programming per se.
Quite the opposite, in fact. To use any language, you need to understand
the rules and concepts for that language. Applying ideas from one
directly to another is only likely to lead to problems.
Ideally, concepts will be shared within a given field as that reduces
confusion when moving from one thing to another. However, one cannot
sensibly use a given term or idea unless it is known to have the same
meaning in both cases.
> <undefined> value means that the entity you tried to access doesn't
> exists
The undefined value may be obtained when a property doesn't exist, but
it may also be obtained for a declared, but uninitialised variable, or
for a property explicitly assigned that value.
> in the current execution context.
Execution contexts have no relevance to the undefined value: they affect
scope.
> Technically it means that this entity never was initialized: ...
No, that is only one possible instance of its use.
> Wherever whenever we had an assignment then we
> don't have an undefined entity there anymore.
A given property would cease to be non-existent as assignment
necessarily creates that property if it didn't already exist. That
doesn't preclude said property from having the value, undefined.
> Rather simple, is not it?
You tell us. I'm certainly not the one that's confused.
> Yet there can be an unforeseen confusion in JavaScript due to the
> erroneous decision to let undefined value to be *assigned*: ...
It is a value, and like any other value, it may be assigned. What's
confusing about that?
> But if one learned well what does <undefined> mean ..., she will
> never be confused.
Indeed. You obviously haven't reached that stage yet.
[snip]
> 1)
> var arr = ['A',,'C'];
> This construct creates an array with tree members (indicies 0,1,2) and
> corresponding values 'A', undefined, 'B'
I don't think I'll ever understand why you cannot see that to be wrong.
> 2)
> var arr = ['A',undefined,'B'];
> This construct is nothing but full version of the shortcut 1)
No, it is not, for reasons explained far too many times than should be
necessary.
> 3)
> var arr = new Array(3);
> arr[0] = 'A';
> arr[1] = undefined;
> arr[2] = 'B';
> This construct is a full functional equivalent of 1) and 2) ...
Of the latter, yes, but not the former.
[snip]
> for (var prop in arr) {
> window.alert(prop + '=' + arr[prop]);
> }
>
> Withing the given <undefined> definition Firefox is the only one
> (compared to Opera and IE) acting properly in each case.
No, it isn't.
> Opera and IE are acting wrongly
No, they are not.
> and more over differently of each other.
As usual, you've posted code without explaining what you expect or, in
this case, what you even see. It doesn't help that of the three
definitions of the array, arr, that you've posted, one is expected to
work differently than that the other two.
In any case, I already stated that IE acts incorrectly with an
explicitly-defined undefined property value, so you aren't providing any
new information.
> arr[1] *is* defined in all three cases
No, it is not.
> but it contains undefined value.
In a conforming implementation, the internal [[Get]] method will return
the value, undefined, for the property name '1' because that property
does not exist in the first array definition. With the latter two, it
will return the same value because the property does exist, and it has
been given that value.
> That is the core glitch in the specs, because there is no equality
> between an initialized variable holding undefined value (arr[1]) and
> a non-initialized variable (say arr[1001]).
Both the Object.prototype.hasOwnProperty method and the in operator can
be used to determine if an object has a particular property. The former
considers the object itself only, whilst the latter includes the
prototype chain.
> If array member ever was initialized, it does stay initialized, no
> matter what assignments you make to it.
Well, yes. One can hardly give a property a value and expect it to
suddenly disappear.
> The one who still remembers what does <undefined> means in the
> programming will also *never* expect that
> arr[2] = undefined; // just another assignment
> will be *equal* to
> delete arr[2]; // send identifier:value pair to the non-existence
And a good thing, too, because those expression statements are not equal.
[snip]
Mike
VK
>> doesn't exists in the current execution context.
> Not in javascript.
Everywhere in the programming languages made by humans.
> In javascript Undefined is a single value of a single type,
> exactly like Null is a single value of a single type.
I am not aware of Undefined (capital 'U') value in JavaScript nor of
Null (capital N) value. That seems like ECMAScript crap, if not then
show them to me.
I am aware of Global properties:
undefined (small 'u')
Infinity
NaN
There is also null (small 'n') which is not a property of Global, never
declared yet known to the script from the very beginning.
>> it means that this entity never was initialized:
>> "it has never seen the assignment sign
>> (=) from its right".
> Then it would not be possible to assign an undefined value.
You're hitting the border of understanding of the problem! Don't loose
your
concentration now.
> While in reality it is extremely easy to assign an undefined value.
I said don't loose the concentration :-) :-(
Don't think of "what they said I can do with it?" and keep thinking on
"what is it?"
> What is an "undefined entity" in relation to javascript?
The same as in the relation to any other language:
"this entity never existed or doesn't exist anymore".
> As the undefined value is just a value
> it should be possible to assign it.
We are loosing him... Oxygen! :-)
Infinity - endless infinity
(Number.POSITIVE_INFINITY - from MAX_VALUE and up to infinity)
(Number.NEGATIVE_INFINITY - from MIN_VALUE and down to infinity)
NaN - not a number, something what even not equal to itself
null - this entity contains no valid data
undefined - this entity doesn't exist
...sure: regular values just like 0, 1, "foobar"... no difference at
all :-)
Or maybe human mind's *abstractions* brought into programming context
to
*compare* with or (in case with null) to mark data holders as free for
garbage
collection?
I even recall some *really* old discussions about null and how bad is
it that they did not make it a Global property "just like everything
else". I'm glad they didn't and I'm sorry they violated poor undefined.
IMHO
VK
> > to talk with person who shows to everyone: "there is only two opinions:
> > my opinion and wrong opinion".
>
> I find Richard's posts to be educative and informational. Sometimes I
> learn a lot about the innards of JavaScript just by looking at his
> replies to VK's ramblings :)
Richard Cornford is the oldest clj poster (by the posting period) after
Jim Ley (1999), but Jim Lay posts very rarely now.
Richard Cornford is also official group FAQ editor and poster since
March 2004 and till very recently.
If you got a code from Rechard, you can be sure that it works and what
thoughts are being put to make it work in the best way.
At the same time it is a stabbering a**h***, f* paper eater, ennemie of
progress, and many other things I hate. :-) / :-|
scrip...@gmail.com
Ray написав:
> scrip...@gmail.com wrote:
> > I never was against an accurate information. But it is not a pleasure
> > to talk with person who shows to everyone: "there is only two opinions:
> > my opinion and wrong opinion".
>
> I find Richard's posts to be educative and informational. Sometimes I
> learn a lot about the innards of JavaScript just by looking at his
> replies to VK's ramblings :)
(because half of Richard's replies is quotes from ECMA-262-3 and the
rest is talks like "you dumbass").
You can just read the specification.
> > I believe that you are real JS guru, but sometimes you realy rough with
> > people. BTW you are not the only man here who love and know JS.
>
> And... ? Rough with who?
have own opinion) it is not enouh to be rough.
Val
Richard Cornford
>>> <undefined> value means that the entity you tried to access
>>> doesn't exists in the current execution context.
>
>> Not in javascript.
>
> Everywhere in the programming languages made by humans.
So you can cite examples of other languages that have a concrete
manifestation of something called 'undefined'? Because in javascript
there is a value of the Undefined type the meaning of undefined within
the language is specific and certain. You preference for some vague
concept derived from your misconceptions of other languages does not
alter the fact that in javascript the meaning is specific.
> > In javascript Undefined is a single value of a single type,
> > exactly like Null is a single value of a single type.
>
> I am not aware of Undefined (capital 'U') value in JavaScript nor of
> Null (capital N) value.
That will neither be the first thing nor the last thing that you are
unaware off.
> That seems like ECMAScript crap, if not then
> show them to me.
The type names in ECMAScript have initial upper case letters. That
allows the type to be distinguished from the value whenever doing so is
significant (which is never really is as far as Undefined and Null are
concerted as each type only has one value).
> I am aware of Global properties:
> undefined (small 'u')
> Infinity
> NaN
>
> There is also null (small 'n') which is not a property of Global,
No, it is a null literal. (undefined, Infinity and NaN are just the
Identifiers of global variables as far as javascript is concerned, and
all may be overwritten with new values).
> never declared yet known to the script from the very beginning.
It is part of the languae (ECMA 262 3rd Ed. Section 7.8.1):-
| 7.8.1 Null Literals
| Syntax
| NullLiteral ::
| null
|
| Semantics
| The value of the null literal null is the sole value of the Null
| type, namely null.
- a literal, like - true - and - false - are literals of Boolean type.
>>> it means that this entity never was initialized:
>>> "it has never seen the assignment sign
>>> (=) from its right".
>
>> Then it would not be possible to assign an undefined value.
>
> You're hitting the border of understanding of the problem! Don't
> loose your concentration now.
No, I am explaining why your assertion of meaning must be false. If
something really did mean that "it had never seen the assignment sign"
then assignment of that something must be precluded.
>> While in reality it is extremely easy to assign an undefined value.
>
> I said don't loose the concentration :-) :-(
It is a fact that the undefined value can be assigned to variables and
object properties.
> Don't think of "what they said I can do with it?" and keep thinking
> on "what is it?"
What it is is a value, and values can normally be assigned, unless they
are only used internally like 16 bit unsigned integers, but undefined
is not only used internally.
>> What is an "undefined entity" in relation to javascript?
>
> The same as in the relation to any other language:
> "this entity never existed or doesn't exist anymore".
The undefined value is not an entity that never existed or has ceased
to exist. It is the single value of the Undefined type.
>> As the undefined value is just a value
>> it should be possible to assign it.
>
> We are loosing him... Oxygen! :-)
Is there a reason that you think values that are available in a
language should not be assignable?
> Infinity - endless infinity
<snip>
IEEE 754 Infinity.
> NaN - not a number, something what even not equal to itself
> null - this entity contains no valid data
In javascript null is a single primitive value of the Null type.
> undefined - this entity doesn't exist
In javascript undefined is a value, and so certainly does exist, along
with anything to which the undefined value is assigned.
> ...sure: regular values just like 0, 1, "foobar"... no difference at
> all :-)
To the extent that they are all values of some type or another they are
not different.
> Or maybe human mind's *abstractions* brought into programming
> context to *compare* with or (in case with null) to mark data holders
> as free for garbage collection?
What are you wittering on about now. Are you proposing that null is
used to mark "holders" as free for garbage collection? How does that
work then?
> I even recall some *really* old discussions about null and how
> bad is it that they did not make it a Global property "just like
> everything else". I'm glad they didn't and I'm sorry they violated
> poor undefined.
There is little point in your recalling a discussions that if it was
worth while will have gone straight over your head, and you would have
misunderstood anyway.
> IMHO
Your opinions are, as always, worthless.
Richard.
Matt Kruse
> <undefined> value means that the entity you tried to access doesn't
> exists in the current execution context.
Try to think of it this way:
Undefined is like your knowledge of javascript - it has been declared,
but currently holds no value.
Actually, I don't understand why such knowledgeable people as Richard and
Michael take their time to respond to you in such detail. You are clearly
wrong. It's not even a matter of opinion or arguing about which methods of
development are best. A simple form-letter followup posted once to each of
your uninformed threads would be quite sufficient as a warning against the
information contained in the post for anyone finding it in the future via
google groups, for example.
<FAQENTRY>
VK is a clueless troll. Disregard everything he writes.
</FAQENTRY>
PS: VK, do you have a web site where we can see your advanced theories in
action? Actions always speak louder than words. Thanks!
--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Richard Cornford
>>> I never was against an accurate information. But it is not a pleasure
>>> to talk with person who shows to everyone: "there is only two opinions:
>>> my opinion and wrong opinion".
>>
>> I find Richard's posts to be educative and informational. Sometimes I
>> learn a lot about the innards of JavaScript just by looking at his
>> replies to VK's ramblings :)
>
> Richard Cornford is the oldest clj poster (by the posting period) after
> Jim Ley (1999), but Jim Lay posts very rarely now.
Trust you to not even be able to work out a simple chronological
sequence. There are at least half a dozen regular contributors to this
group who pre-data my participation, by many years in some cases.
> Richard Cornford is also official group FAQ editor and poster since
> March 2004 and till very recently.
Most people take not knowing what they are talking about as a reason
for being silent.
> If you got a code from Rechard, you can be sure that it works
> and what thoughts are being put to make it work in the best way.
Your opinion is, as always, utterly worthless.
> At the same time it is a stabbering a**h***, f* paper eater, ennemie
> of progress,
This is a progress in the sense of doing things worse than they have
ever been done before? (quite an achievement when you are taking web
development)
> and many other things I hate. :-) / :-|
Do you hate the truth? You seem to give it a very wide berth.
Richard.
TC
VK wrote:
> >> <undefined> value means that the entity you tried to access
> >> doesn't exists in the current execution context.
>
> > Not in javascript.
>
> Everywhere in the programming languages made by humans.
Not so. There's at least one other common programming language with a
similar construct (VBA, with vbEmpty).
TC (MVP MSAccess)
http://tc2.atspace.com
Michael Winter
[snip]
> Actually, I don't understand why such knowledgeable people as Richard
> and Michael take their time to respond to you in such detail.
It used to be that I thought I might manage to teach VK something.
Experience has taught /me/ otherwise.
> A simple form-letter followup posted once to each of your uninformed
> threads would be quite sufficient as a warning against the
> information contained in the post for anyone finding it in the future
> via google groups, for example.
It's tempting, but would it be convincing? At least a discussion puts
some weight behind a reply. It even seems to be worthwhile for some
people reading, even if it is above VK's head.
> <FA**NTRY>
> VK is a clueless troll. Disregard everything he writes.
> </FA**NTRY>
One must remember that, with random chance alone, VK's got to get
something right occasionally. :-)
[snip]
Mike
VK
> Actually, I don't understand why such knowledgeable people as Richard and
> Michael take their time to respond to you in such detail.
You may ask them. Primarely because "my word has to be the last one",
secondly because "where can be only one king", thirdly because there is
something to analize and find an explanation, even if it seems to have
=>0 practical value (just guessing).
besides {1,,2] there are now [1,undefined,2] discrepancies among
browsers. Did you really know that before this thread? I doubt it very
much, I give 99% chance that you played with the script I posted, then
you found relevant bug filings/discussion and now from the top of the
newly obtained knowledge you're saying what you're saying.
> A simple form-letter followup posted once to each of
> your uninformed threads would be quite sufficient as a warning against the
> information contained in the post for anyone finding it in the future via
> google groups, for example.
Start from
<http://groups.google.com/group/comp.lang.javascript/msg/f3e08dd5bf3c8641>
and go down by dates.
> <FAQENTRY>
> VK is a clueless troll. Disregard everything he writes.
> </FAQENTRY>
...
> PS: VK, do you have a web site where we can see your advanced theories in
> action? Actions always speak louder than words. Thanks!
I do program for money on per project basis, so not every piece of code
is available for public domain. Also what point of it would be to
discuss say a behaviors library or a SVG/VML library in clj?
To listen about how useless and harmful 3rd party libraries are as
such? That it doesn't "work" for IE4/Safary/GodKnowsWhat 0.x ? That
namespaces do not exist and not allowed in HTML so "this is wrong no
matter if it works or not"?
This kind of crap I'm getting enough without posting anything.
You may look in the archives for my sample of attachable AJAX behavior
sample. Together with its Gecko binding twinpair it was successfully
destributed. I've never seen
any reaction on it in clj, even regular "put him down" follow-ups. That
was totally uninteresting I guess.
Richard Cornford
> Matt Kruse wrote:
>> Actually, I don't understand why such knowledgeable
>> people as Richard and Michael take their time to
>> respond to you in such detail.
>
> You may ask them. Primarely because "my word has to
> be the last one", secondly because "where can be only
> one king", thirdly because there is something to analize
> and find an explanation, even if it seems to
So you are not even considering that it is because you are wrong and if
nobody points that out you will remain wrong?
> have =>0 practical value (just guessing).
Zero or grater practical value? There is that screwed up logic that
makes you such a spectacularly bad programmer.
> besides {1,,2] there are now [1,undefined,2] discrepancies
> among browsers. Did you really know that before this thread?
The whole subject has been gone into in depth before. But are you
proposing that anyone would have been better informed as a result of
your completely false original post?
> I doubt it very much,
You should not project your own limitations onto others.
> I give 99% chance that you played with the script I
> posted, then you found relevant bug filings/discussion
> and now from the top of the newly obtained knowledge
> you're saying what you're saying.
You are forgetting that the "new Array() vs []" thread resolved this
question before you even posted. But I will wager than the people who
did learn something from this thread learnt it from the corrections you
received and not from anything you actually posted.
>> A simple form-letter followup posted once to each of
>> your uninformed threads would be quite sufficient as
>> a warning against the information contained in the
>> post for anyone finding it in the future via google
>> groups, for example.
>
> Start from
>
<http://groups.google.com/group/comp.lang.javascript/msg/f3e08dd5bf3c864
1>
> and go down by dates.
So how many times have you been corrected by now? And how many times on
the same subject reportedly?
>> <FA***RY>
>> VK is a clueless troll. Disregard everything he writes.
>> </FA***RY>
I don't think VK is a troll, that would imply malice. Mental illness is
the most comprehensive explanation of his posting record.
>> PS: VK, do you have a web site where we can see your advanced
>> theories in action? Actions always speak louder than words. Thanks!
<snip>
> ... ? That it doesn't "work" for IE4/Safary/GodKnowsWhat 0.x ?
> That namespaces do not exist and not allowed in HTML so
> "this is wrong no matter if it works or not"?
> This kind of crap I'm getting enough without posting anything.
Your not posting would certainly be an ideal outcome from my point of
view.
> You may look in the archives for my sample of attachable
> AJAX behavior sample. Together with its Gecko binding
> twinpair it was successfully destributed. I've never seen
> any reaction on it in clj, even regular "put him down"
> follow-ups.
You have added not seeing to not understanding. But didn't the
overwhelming disinterest in the Google group you started on the subject
tip you off that not even the least well informed web developers are
interested in a strategy that requires more than double the work to
achieve on two browsers something that is inherent in the language (and
so all current implementations) already?
> That was totally uninteresting I guess.
It is interesting when you demonstrate something that an be achieved in
that way that cannot be achieved in any other way, and even then it is
only interesting in relation to specialist Intranet applications. Your
record on actually demonstrating anything is so poor that it is unlikely
that you ever could.
Richard.
John G Harris
<school...@yahoo.com> writes
<snip>
><undefined> value means that the entity you tried to access doesn't
>exists in the current execution context. Technically it means that this
>entity never was initialized: "it has never seen the assignment sign
>(=) from its right". Wherever whenever we had an assignment then we
>don't have an undefined entity there anymore. Rather simple, is not it?
>Yet there can be an unforeseen confusion in JavaScript due to the
>erroneous decision to let undefined value to be *assigned*: in
>violation of the very nature of undefined and in violation of any
>programming logic.
>But if one learned well what does <undefined> mean (see the definition
>atop), she will never be confused. She will just smile over some
>passages in the ECMAScript specs.
<snip>
Let's try once again. Call it 'glub' as other names can confuse people.
Whenever a variable is created its initial value is glub; it will keep
that value until some other value is assigned to the variable.
ECMAScript v2 :
Originally we had
glub == null
There was no way of telling these two values apart. Consequently there
was no point in allowing programmers to assign glub to a variable. They
might as well assign null as that had the same effect.
(Actually you could tell them apart : you could make the program crash
if the value was glub, but this wasn't much use as try ... catch had yet
to appear.)
ECMAScript v3 :
We still have
glub == null
but we also have
!( glub === null )
so there is now a way of telling them apart. People who write tricky,
and probably fragile, code would want to be able to assign either value
to variables. It had to become legal to write
x = glub;
and this had to make the value of x become glub, the same value that x
had before it was first assigned to.
By rights glub should be a reserved word just as null and true and false
are. But retrospectively making it impossible to use 'glub' as an
identifier risks crashing some high profile web site who've already used
the name 'glub', leading to very loud shouting and threats of lawsuits.
To avoid this, glub is made a global variable with the attribute Don't
Delete, but *not* Read Only so overwriting it won't cause problems in
old code.
There's another problem. 'glub' is a word that is meaningless in English
so many web designers would find it difficult to remember. 'glub' might
also be a rude word in some populous non-English language.
So, let's call it 'undefined'. That's just an arbitrary name; its
meaning is still glub.
>The one who still remembers
>what does <undefined> means in the programming
<snip>
The C++ standard uses the term "undefined behaviour" a lot. The standard
specifies the behaviour of "undefined behaviour" very precisely, thus
demonstrating that your "one" has a defective memory.
John
--
John Harris
Ray
scrip...@gmail.com wrote:
> ECMA-262-3 specification is even more informative and eductional
> (because half of Richard's replies is quotes from ECMA-262-3 and the
> rest is talks like "you dumbass").
> You can just read the specification.
Nah... I prefer reading something like Mr. Flanagan's book. But
Richard's post I read because often they teach me something new about
JS.
> > > I believe that you are real JS guru, but sometimes you realy rough with
> > > people. BTW you are not the only man here who love and know JS.
> >
> > And... ? Rough with who?
> Who cares? IMHO even if somebody writes something realy wrong (or just
> have own opinion) it is not enouh to be rough.
Well the thing is when it comes to a spec, there's not much room for an
opinion, is there? Either you're wrong or you're right. And personally,
I appreciate Richard's effort to inform people in this newsgroup of
what is right.
If you write something really wrong, get corrected, and get why you are
corrected, I doubt he'll be rough :)
> Val
Randy Webb
<snip>
> As usual, you find yourself alone, yet you're either too stubborn to
> admit your mistake, or too stupid to recognise it.
I vote the latter and is compounded by the former.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Randy Webb
>>> I never was against an accurate information. But it is not a pleasure
>>> to talk with person who shows to everyone: "there is only two opinions:
>>> my opinion and wrong opinion".
>> I find Richard's posts to be educative and informational. Sometimes I
>> learn a lot about the innards of JavaScript just by looking at his
>> replies to VK's ramblings :)
>
> Richard Cornford is the oldest clj poster (by the posting period) after
> Jim Ley (1999), but Jim Lay posts very rarely now.
I know of at least 3 that have been around longer than Richard other
then Jim Ley.
Randy Webb
> One must remember that, with random chance alone, VK's got to get
> something right occasionally. :-)
That chance hasn't come around yet though.
VK, post this:
<quote>
The FAQ for this group is at http://jibbering.com/faq
</quote>
Then, you can be right for once......
VK
> Try to think of it this way:
> Undefined is like your knowledge of javascript - it has been declared,
> but currently holds no value.
The question is not what does say [0,,2] suppose
to do upon ECMAScript specs. They could require
that on each elision the screen has to change
the bgcolor in the palette sequence.
The question is what does [0,,2] *mean* in the
programming context. For my deranged mind it
means the same since at least 1998: explicit
initialization of all array members (reflected
as properties in the underlying object).
Netscape 4.x (including Netscape 4.5 used as
basis for ECMAScript) behaved this way and no
one had any problem with it - though the usage
of elision is very rarely needed with a proper
programming.
But (and it brings us back to the definition of
"a bug") if a bug is only a non-compliance to
a written specification then
[0,,2] indeed became a bug overnight after
December 1999.
So shall be it. It is a "Mozilla bug".
<OT>
About "VK is extremely bad programmer, doesn't know JavaScript" and
such.
A from behind the corner burking of this kind do not put me down but of
course it does upset me. I wrote my fist line of JavaScript
in 1996, and in 1998 my PopUp calendar (IE4/NN4)
became a standard de-facto in Contra Costa county
with 30 licenses sold in the Bay Area and one even
to Australie. AFAIK all this happened years before
some of my critics even knew about JavaScript not
talking about programming on it.
As of to "show up" now: there is an extra obstacle as
don't want to reveal my personality and I want to stay
VK in c.l.j. This question was asked before and answered:
this way I can discuss my clients and their demands (often
the most idiotic ones) w/o letting to map - at least legally -
my name to my statements. That gives me a "freedom speech"
I'd like to keep. But indeed I may have to clean up and post
some samples of modern web-development even as a subject
of screaming and spitting. ECMAScript did not change
for almost 7 years now, and IMHO pathetic discussions over say
commas in array initializer is a sure sign of degradation.
Some fresh blood may be needed :-)
Also we take Matt's suggestion for action (that the code
samples is everything and words are nothing), then c.l.j.
would become a very silent place :-)
>From all current and former cabbal members I know for sure
only about Douglas Crockford (JSON) and Matt himself (AjaxToolbox)
that they can write quality programs in JavaScript.
>From say Richard Cornford in three years I've seen only one
self-contained application: a rather tedious scrollable table
script written more than two years ago. Ever since I did not see
a piece longer then a few lines (a dependent subroutine or a part
of dependent subroutine) - besides endless ECMA quoting.
</OT>
<http://groups.google.com/group/comp.lang.javascript/msg/f3e08dd5bf3c8641>
null = Nothing
>> <undefined> value means that the entity you tried to access
> >> doesn't exists in the current execution context.
> > Not in javascript.
> Everywhere in the programming languages made by humans.
Not so. There's at least one other common programming language with a
similar construct (VBA, with vbEmpty).
Perl
What happens if you use a scalar variable before you give it a value?
Nothing serious, and definitely nothing fatal. Variables have the undef
value before they are first assigned. This value looks like a zero when
used as a number, or the zero-length empty string when used as a
string. You will get a warning under Perl's -w switch, though, which is
a good way to catch programming errors.
> So you can cite examples of other languages that have a concrete
> manifestation of something called 'undefined'?
You mean like with Infinity or undefined as "real" entities stored
somewhere?
I don't know of such languages or systems and I doubt very much
they will ever appear: though it would be interesting to touch and feel
say
Infinitity while remaining in this world :-)
Alas everywhere (including JavaScript) these are just subroutines and
banal
1's and 0's interpreted in certain way in the program stream.
> Because in javascript
> there is a value of the Undefined type the meaning of undefined within
> the language is specific and certain.
That is exactly the point I've made before: about the danger of
interpreting
a *language* by reading machine *engine* specifications. Low level
processes
keeping 1's and 0's in the needed order are not the same as higher
level
programming entities. On the lower level naturally there is no NaN or
Infinity or undefined or null or so. Yet they have to be represented
somehow
VK
VK wrote:
<snip>
> of dependent subroutine) - besides endless ECMA quoting.
> </OT>
woops... I posted my sketches by mistake after the end of the post.
It's supposed to end on</OT>
anything below it went trough by occasion.
Very embarassing... :-(
Richard Cornford
> Matt Kruse wrote:
> > Try to think of it this way:
> > Undefined is like your knowledge of javascript - it has been declared,
> > but currently holds no value.
>
> The question is not what does say [0,,2] suppose
> to do upon ECMAScript specs. They could require
> that on each elision the screen has to change
> the bgcolor in the palette sequence.
If someone assert that it should do one thing the question very much is
whether it should do that. You where the one asserting that elisions
should directly result in array index elements being created on an
array object, that was a wrong interpretation of what should happen.
> The question is what does [0,,2] *mean* in the
> programming context.
If we are talking about javascript the only relevant meaning is what it
means in javascript. What interpretations it may be subject to in other
contexts is completely irrelevant (isn't it a syntax error in Java?
does that make it a syntax error everywhere else?).
> For my deranged mind it
> means the same since at least 1998: explicit
> initialization of all array members (reflected
> as properties in the underlying object).
That is not quite enough of a sentence to mean anything, so it probably
is the product of your mind.
> Netscape 4.x (including Netscape 4.5 used as
> basis for ECMAScript)
Netscape 4 was an ECMA 262 2nd edition implementation.
> behaved this way and no
> one had any problem with it - though the usage
> of elision is very rarely needed with a proper
> programming.
Which is why implementation bugs in this area have little practical
impact, though (with the exception of Microsoft) they are being fixed.
> But (and it brings us back to the definition of
> "a bug") if a bug is only a non-compliance to
> a written specification then
> [0,,2] indeed became a bug overnight after
> December 1999.
No, it became a bug when people announced that their script engines
were ECMA 262 3rd edition implementations.
> So shall be it. It is a "Mozilla bug".
Yes, they claim to implement ECMA 262 3rd ed, so they can recognise
when they have a bug.
> <OT>
> About "VK is extremely bad programmer, doesn't know JavaScript" and
> such.
VK writes programs that either demonstrate a failure to understand what
the code written actually does, or a tendency to do pointless things
with a full knowledge that they are pointless (such as returning null
from a function that is only used as constructor and putting the - void
- operator in front of a function call even though the result of the -
void - expression is never used).
> A from behind the corner burking of this kind do not put me down
> but of course it does upset me.
While a productive response would be to realise that the criticism is
valid and improve your knowledge and understanding to the point were
you could avoid writing fundamentally poor code.
> I wrote my fist line of JavaScript
> in 1996, and in 1998 my PopUp calendar (IE4/NN4)
> became a standard de-facto in Contra Costa county
> with 30 licenses sold in the Bay Area and one even
> to Australie.
In a world where the general standard is appalling getting people who
don't know any better themselves to use poor scripts is not much of an
achievement.
> AFAIK all this happened years before
> some of my critics even knew about JavaScript not
> talking about programming on it.
Yes, there seem to be many people who have acquired an infinitely
superior understanding of the subject in a relatively short period of
time. They have done that by recognising when they have been wrong and
doing something to change that. Your intransigence and groundless
belief that the understanding you think you currently have is already
faultless gets in the way of your progressing.
> As of to "show up" now: there is an extra obstacle as
> don't want to reveal my personality
It is your identity that you don't want to reveal (for very obvious
reasons), your personality is an open book.
> and I want to stay VK in c.l.j.
Well at least that will help people find the extent of your folly in
the archives.
<snip>
> ECMAScript did not change
> for almost 7 years now,
Which is a good thing as the implementations are now very stable in
their conformance and the few remaining bugs are restricted to areas
that are almost never used. That makes understanding what ECMA 262 says
and means a very good practical guide to what can be expected of
implementations.
> and IMHO pathetic discussions over say
> commas in array initializer is a sure sign of degradation.
> Some fresh blood may be needed :-)
Then why did you post the original post in this thread? Or is your
problem only that your post was discussed?
> Also we take Matt's suggestion for action (that the code
> samples is everything and words are nothing), then c.l.j.
> would become a very silent place :-)
But opinions on how browser scripting should be done well from people
who do not even understand the code they write are worthless, so seeing
some of the code written by people is a reasonable criteria for
weighting their comments.
> From all current and former cabbal members I know for sure
> only about Douglas Crockford (JSON) and Matt himself (AjaxToolbox)
> that they can write quality programs in JavaScript.
Not quite a sentence again
> From say Richard Cornford in three years I've seen only one
> self-contained application: a rather tedious scrollable table
> script written more than two years ago. Ever since I did not see
> a piece longer then a few lines (a dependent subroutine or a part
> of dependent subroutine) - besides endless ECMA quoting.
And does the scrollable table work in more actual browsers that any
equivalent script available, and cleanly degrade to usable HTML in
every browser where it is not actively supported? Did it take less than
6 hours to write from start to its current state using pre-existing low
level components? And has it not needed any maintenance during its life
to date?
> </OT>
> <http://groups.google.com/group/comp.lang.javascript/msg/f3e08dd5bf3c8641>
Why, when you have made yourself look a total idiot do you insist on
trying to direct attention to the irrelevant? It doesn't fool anyone.
> null = Nothing
Are you expressing one of your fantasies or trying to imply something
about javascript, where null is the singe value of the Null type?
> >> <undefined> value means that the entity you tried to access
>>>> doesn't exists in the current execution context.
>
>>> Not in javascript.
>
>> Everywhere in the programming languages made by humans.
>
> Not so. There's at least one other common programming language with a
> similar construct (VBA, with vbEmpty).
You have messed up your quoteing.
> Perl
> What happens ... .
<snip>
Perl defines javascript how?
>> So you can cite examples of other languages that have a concrete
>> manifestation of something called 'undefined'?
>
> You mean like with Infinity or undefined as "real" entities stored
> somewhere?
I mean something that is part of the langue, can be directly employed
by a programmer and is called 'undefined'. (The question would make
more sense if you had not edited its context away, but then you need it
to be derived of its context else your responses will look really
insane.)
> I don't know of such languages or systems and I doubt very much
> they will ever appear: though it would be interesting to touch and feel
> say Infinitity while remaining in this world :-)
So is your position then that the real meaning of something that you
see as unique to javascript is determined by the meaning of something
else somewhere else?
> Alas everywhere (including JavaScript) these are just subroutines
> and banal 1's and 0's interpreted in certain way in the program
> stream.
Your point?
>> Because in javascript there is a value of the Undefined type
>> the meaning of undefined within the language is specific and
>> certain.
>
> That is exactly the point I've made before: about the danger of
> interpreting a *language* by reading machine *engine*
> specifications. Low level processes keeping 1's and 0's in the
> needed order are not the same as higher level programming
> entities. On the lower level naturally there is no NaN or
> Infinity or undefined or null or so. Yet they have to be represented
> somehow
A value is a concept in programming languages, and they will have
representations in the language's implementation. They are also used;
assigned to variables/properties, returned from functions/methods and
so on. Your problem is that when you see - undefined - you are applying
a concept to it that is not the concept of a value, and that is sending
you off on a flight of fantasy.
A declared but not initialised variable may be a concept. Marking a
variable that is in that condition by provisionally assigning a
(preferably unique and fully identifiable) value to the variable is a
reasonable practice, but that does not turn the value assigned into the
concept of an uninitialised but declared variable.
You won't see that, but then logic has never featured in your intellect
(one of the reasons your code is so poor).
Richard.
Dr John Stockton
dated Mon, 11 Sep 2006 09:36:08 remote, seen in
news:comp.lang.javascript, VK <school...@yahoo.com> posted :
>Richard Cornford is also official group FAQ editor and poster since
>March 2004 and till very recently.
He does not seem, however, to be achieving anything in those roles. His
time would be better spent in doing something more constructive than
arguing with you.
It's a good idea to read the newsgroup and its FAQ.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.