Is array notation special?

[Sam Kong]

Hello!

My question would not be very practical but just out of curiosity.
In JavaScript, Array is a subclass of Object.
Well maybe not exactly... but sort of...

For normal objects, you can access members by writing either of the
two.

obj.memberName
obj["memberName"]

However, Array allows number in the bracket like arr[3].

My question is...
Is the Array's special case embedded in the language or can we make
such special case using general JavaScript syntax?
In other words, can we make our custom Array class in JavaScript?


Thanks.
Sam

 

[VK]

Hello!

My question would not be very practical but just out of curiosity.
In JavaScript, Array is a subclass of Object.
Well maybe not exactly... but sort of...

Not "sort of" but exactly.
alert(Array.constructor instanceof Object.constructor); // true

For normal objects, you can access members by writing either of the
two.

obj.memberName
obj["memberName"]

However, Array allows number in the bracket like arr[3].
My question is...
Is the Array's special case embedded in the language or can we make
such special case using general JavaScript syntax?
In other words, can we make our custom Array class in JavaScript?

<blockquote
cite="http://www.geocities.com/schools_ring/ArrayAndHash.html">
// JavaScript "baby care" in action: it's being so nice
// to put missing quotes on the background, so invalid key 2
// would become a valid CDATA string:
var hashObject = {2 : "value"}

// JavaScript "baby care" is going too far or not far enough,
// depending on how do you look at that.
// Now it thinks that you meant to say 2:cows (2 - key, cows - value)
// but doesn't dare to insert the "missing" colon.
// Instead a syntacs error will be generated.
var hashObject = {2cows : "value"}
</blockquote>

<blockquote
cite="http://www.geocities.com/schools_ring/ArrayAndHash.html">
2) Array as hash
JavaScript doesn't have "final" constructors. Each constructor (and
object build using this constructor) can be extended to have new
properties at any time. So any object is a potential hash. So Array
itself can be used both like array and like hash. It reminds a
two-story house with separate exits. The word separate is very
important here, because arrayObject knows nothing about it's other hash
side, so does not its hash side about array. Kind of objective
schizophrenia...
So if you occasionally do:
arrayObject[stringValue] = value;
no error will be shown. arrayObject will get new property stringValue
(new stringValue:value hash pair). But it will neither be counted into
arrayObject.length nor it will processed by array methods.
</blockquote>

 

[Richard Cornford]

My question would not be very practical but just out of
curiosity.
In JavaScript, Array is a subclass of Object.

In a class-less language like javascript that is not strictly true (and
may be misleading).

Well maybe not exactly... but sort of...

Yes, 'sort of' but not necessarily usefully so.

For normal objects, you can access members by writing
either of the two.

obj.memberName
obj["memberName"]

However, Array allows number in the bracket like arr[3].

Object also allow numbers in the brackets; You can create and object
such as:-

var o = new Object();
o[6] = 'anything';

- and then retrieve the property as:-

var x = o[6];

- or:-

var x = o['6'];

And you can define an object as:-

var o = {'6':'anything'};

- and then retrieve the property as:-

var x = o[6];

- or:-

var x = o['6'];

And you can even similarly define an object as:-

var o = {6:'anything'};

- but Mac IE 5 will get that one wrong so it is best not to use it.

My question is...
Is the Array's special case embedded in the language
or can we make such special case using general JavaScript
syntax?

There is no special Array accessing syntax in javascript. The only
syntaxes for reading the properties of objects are dot notation property
accessors and bracket notation property accessors. You cannot use dot
notation with the 'array index' properties of Arrays because the tokens
in a dot notation property accessor must qualify as an Identifier and an
Identifier may not start with a decimal digit. Bracket notation does not
impose any restriction on the character sequence that is the (implicitly
type-converted, if necessary) string result of the expression within the
brackets. So bracket notation is the only possibility when accessing the
properties of an Array that are named after non-negative integers.

In other words, can we make our custom Array class in
JavaScript?

There are no classes in javascript. You can create specially augmented
Array objects and do that augmentation in a way that has sufficient
likeness for each object to allow the results to conceptually qualify as
a sub-class.

What you cannot successfully do with an Array is use one as the
prototype for an object and inherit the Array-specific behaviour
(related to the assignment of values to 'array index' properties and
the - length - property) through the prototype chain. This is because
the Array's special behaviour is attributed to a specification-defined
internal [[Put]] method and that method is only used when assigning to
the object itself not for objects for which it is a prototype (also,
ambiguities in the specified definitions of Array methods have left very
few of them practically transferable to other types of object, even
though they should be).

Richard.

 

[Richard Cornford]

Sam Kong wrote:

Not "sort of" but exactly.

No, anything but 'exactly'. Even 'sort of' is pushing the relationship.
The Array object is an augmented instance of the Native ECMAScript
object, the only type of object (so the only 'class' of object)
javascript has. The Object object is also an augmented instance of the
Native ECMAScript object, as are all other objects in the language.

alert(Array.constructor instanceof Object.constructor); // true

Yet another example of your seeing (but not being able to express)
significance in something that is no more than the consequence of the
specified mechanism, and certainly does not imply any subclass
relationship exists.

Would:-

alert(
(function(){return {};}).constructor
instanceof
Object.constructor
); // true

- imply anything about sub-class relationships? All functions, effective
constructors, methods or otherwise, return true when used as the left
hand operand of - instanceof - when Object.constructor is the right hand
side operand. That ahs no implications for anything beyond the prototype
relationships that apply to function objects.

<blockquote
cite="http://www.geocities.com/schools_ring/ArrayAndHash.html">
// JavaScript "baby care" in action: it's being so nice
// to put missing quotes on the background,

The internal representations of strings do not have quotes, so "to put
missing quotes on the background" is meaningless.

so invalid key 2
// would become a valid CDATA string:

CDATA is a concept that is completely alien to javascript. There is no
such thing as "a valid CDATA string" in javascript, that phrase is just
meaningless in the context of the language. (How many times have you
been told that by now? 20? More?)

var hashObject = {2 : "value"}

// JavaScript "baby care" is going too far or not far enough,
// depending on how do you look at that.
// Now it thinks that you meant to say 2:cows (2 - key, cows -
value) // but doesn't dare to insert the "missing" colon.
// Instead a syntacs error will be generated.
var hashObject = {2cows : "value"}

This incoherent gibberish appears to be attempting to express something
that is utter nonsense.

</blockquote>

<blockquote
cite="http://www.geocities.com/schools_ring/ArrayAndHash.html">
2) Array as hash
JavaScript doesn't have "final" constructors.

Does anything?

... . It reminds a two-story house with separate exits.

That analogy appears to have no connection with the reality of
javascript.

The word separate is very important here, because arrayObject
knows nothing about it's other hash side, so does not its hash
side about array.

Attributing self-knowledge to a javascript object is meaningless. The
javascript Array is an object and it has its non-'array index'
properties in exactly the same way as it has its 'array index'
properties. The degree to which it is aware of having either does not
vary between the two.

Kind of objective schizophrenia...

Or not. (An array is a single object representing a single structure and
having a single mechanism).

So if you occasionally do:
arrayObject[stringValue] = value;
no error will be shown. arrayObject will get new property
stringValue (new stringValue:value hash pair). But it
will neither be counted into arrayObject.length nor it will
processed by array methods.
</blockquote>

That depends always, and only, on whether the evaluated, and
type-converted to string, value of the expression - stringValue -
qualifies as an 'array index' (as defined by the language specification)
or not.

Richard.

 

[VK]

No, anything but 'exactly'. Even 'sort of' is pushing the relationship.
The Array object is an augmented instance of the Native ECMAScript
object, the only type of object (so the only 'class' of object)
javascript has. The Object object is also an augmented instance of the
Native ECMAScript object, as are all other objects in the language.


Yet another example of your seeing (but not being able to express)
significance in something that is no more than the consequence of the
specified mechanism, and certainly does not imply any subclass
relationship exists.

Would:-

alert(
(function(){return {};}).constructor
instanceof
Object.constructor
); // true

- imply anything about sub-class relationships? All functions, effective
constructors, methods or otherwise, return true when used as the left
hand operand of - instanceof - when Object.constructor is the right hand
side operand. That ahs no implications for anything beyond the prototype
relationships that apply to function objects.

alert(Array instanceof Object); // true
alert(Object.isPrototypeOf(Array)); // false

 

[VK]

The internal representations of strings do not have quotes, so "to put
missing quotes on the background" is meaningless.

Right. Must be changed to "converts to string on the background" or
"treats as string literal". The latter is better, but I'd like to keep
the language as simplified as technically possible.

CDATA is a concept that is completely alien to javascript. There is no
such thing as "a valid CDATA string" in javascript, that phrase is just
meaningless in the context of the language. (How many times have you
been told that by now? 20? More?)

I'm aware of CDATA and PCDATA usage. Unfortunately I'm still in search
for a right term for (from strictest to loosest):
1) string literals conforming to CSS class name rules.
2) string literals conforming to ID rules.
3) string literals conforming to JavaScript identifiers rules.
4) string literals conforming to NAME rules.
5) string literals conforming to no rules at all: @#*%$ Hhhh etc.

The best term for 5) I've found so far is CDATA, however bad is it to
apply it here. If there is a better official term, I'll jump on it
gladly.

This incoherent gibberish appears to be attempting to express something
that is utter nonsense.

I asked this question ("why 2 goes as the key, and 2cows doesn't?")
more than one year ago:
<http://groups.google.com/group/comp..._frm/thread/14279b01d86b6497/405dbef998068e6e>

The only answer I got that time was "Everyone should know that" from
which I concluded that no one really knew, so I had to investigate it
myself.

The posted explanation is totally correct: it is indeed not a problem
with the key name by itself, but with JavaScript parser looking at
"2cows" as mistyped 2:cows
....
Error: missing : after property id
Source Code:
var hash = {2cows:2};
....

Attributing self-knowledge to a javascript object is meaningless. The
javascript Array is an object and it has its non-'array index'
properties in exactly the same way as it has its 'array index'
properties. The degree to which it is aware of having either does not
vary between the two.

var arr = new Array(1,2,3);
arr.foo = 'bar';
alert(arr);

 

[Richard Cornford]

Right. Must be changed to "converts to string on the background"
or "treats as string literal".

"Treats as string literal" would be false, as only string literal tokens
would be treated as string literals.

The latter is better,

Typical of you to prefer to say something false.

but I'd like to keep the language as simplified as
technically possible.

It is technically possible for you to omit all words and code entirely,
and that is as simple as language gets.

I'm aware of CDATA and PCDATA usage.

But apparently unaware of their meaning or significance.

Unfortunately I'm still in search
for a right term for (from strictest to loosest):
1) string literals conforming to CSS class name rules.
2) string literals conforming to ID rules.
3) string literals conforming to JavaScript identifiers rules.
4) string literals conforming to NAME rules.
5) string literals conforming to no rules at all: @#*%$ Hhhh etc.

No string literal conforms to no rules at all. String literals conform
to string literal rules in whatever language they exist in.

The best term for 5) I've found so far is CDATA,

It would make as much sense to fabricate your own term by randomly
hitting keys on a keyboard and using whatever resulted. The term you
appear to be searching for is 'string literal', but string literals do
conform to well-defined rules or they are not going to be treated as
string literals.

however bad is it to apply it here.

Of course it is, it doesn't mean anything in the context of javascript.

If there is a better official term, I'll jump on it
gladly.

'string literal'.

I asked this question ("why 2 goes as the key, and 2cows doesn't?")
more than one year ago:

The only answer I got that time was "Everyone should know that"

Yes they should as the syntactically correct tokens in the context of a
property name in an object initialiser are Identifiers, string literals
and numeric literals and - 2cows - is none of those. Everyone should
know what qualifies as an Identifier, a numeric literal or a string
literal, that knowledge is so basic that you can hardly program in
javascript without knowing.

If fact - 2cows - will not be parsed as a single token, it is a numeric
literal token - 2 - followed by an Identifier token - cows -, and will
certainly result in a syntax error wherever it appears in javascript
source code.

from which I concluded that no one really knew,

Typical of you; you read one thing and then understand it to mean the
opposite. Given your tendency to make out that you actually know
something about javascript is it really surprising if you get short
answers when you ask absolutely basic questions with obvious answers?

so I had to investigate it myself.

And like most of your investigations the result was more false than not
knowing at all.

The posted explanation is totally correct:

It is incoherent gibberish. Correctness is not even an issue until the
text is coherent.

it is indeed not a problem with the key name by itself,
but with JavaScript parser looking at "2cows" as mistyped
2:cows

No, it is looking at - 2cows - and applying well-specified tokenising
rules that result in the two tokens - 2 - and - cows - and then seeing
that the - 2 - numeric literal token is not followed by the punctuator
token - : -, that is the only permissible token in that context within
an object initialiser, and so producing a syntax error. It is even an
informative syntax error. There is no need to ascribe any perception of
a typing error to the interpreter, the outcome is the certain
consequence of the application of the specified rules. It is pure
mechanism; blind deterministic mechanical logic.

...
Error: missing : after property id
Source Code:
var hash = {2cows:2};
...

Code that contains erroneous syntax produces a syntax error, and you
will look anywhere but the language's syntax rules for an explanation of
that.

var arr = new Array(1,2,3);
arr.foo = 'bar';
alert(arr);

Whatever significance you may see in that code is irrelevant unless you
are capable of expressing what it is. We can look up the definition of
the - toString - method of Arrays and see that the outcome here is in
accordance with the specification. Again, pure mechanical logic, not
self-awareness (or the lack thereof) on the part of the Array object. If
the Array's - toString - method was replaced with another many
alternative outcomes would be achievable, including one where the array
alerted - "bar, 1, 2, 3" -, which still implies nothing about Arrays
except that their - toString - methods are called when they are
type-converted into strings.

Richard.

 

[Richard Cornford]

alert(Array instanceof Object); // true
alert(Object.isPrototypeOf(Array)); // false

You are at it again. There is no point posting code in which you see
significance if you don't state what that significance is supposed to
be. All you are doing is posting code that does exactly what the
specification say it should do. Nothing can be deduced from that, and
certainly nothing about sub-class relationships as there are no
'classes' in the specification with which this code's behaviour
conforms.

The identifier - Array - refers to a function and all functions return
true when used as the left hand side operand of - instanceof - when the
right hand side operand is the Object constructor.

The Identifier - Object - refers to a function and the - Array -
function does not have the - Object - function on its prototype chain.

Why are the prototype chains of functions of any significance to you at
all?

Richard.