undefined vs. undefined (was: new Array() vs [])

[Michael Winter]

VK wrote:

[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]

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

 

[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;
}
}

 

[Richard Cornford]

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]

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

VK wrote:

[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]

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.

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]

I never was against an accurate information. But it is not a pleasure

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

 

[scriptguru]

Ray напиÑав:

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

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.

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.

Val

 

[Richard Cornford]

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.

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.

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.

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.

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.

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!

 

[Richard Cornford]

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]

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]

Matt Kruse wrote:

[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

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

 

[John G Harris]

<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

 

[Richard Cornford]

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.

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?

I don't think VK is a troll, that would imply malice. Mental illness is
the most comprehensive explanation of his posting record.

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

 

[Ray]

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.

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

 

[Randy Webb]

Michael Winter said the following on 9/11/2006 12:18 PM:

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.