V
VK
We went deep to the jungles of the abstract programming.
I'm afraid only ECMA/ISO guys (or a 3rd-4th grade Computer Science student
who's forced to remember this stuff) would be capable to finalize the
discussion.
I personally don't see what you see in the 11.2.1 of ECMA specs.
IMHO it just says that the Object.Property construct can be presented
in two ways (or a combination of both):
by literals: ObjectName.PropertyName
by expressions: (ExpressionForObjectName)[ExpressionForPropertyName]
The same paragraph states that the final result of evaluation in both cases
is an Identifier (I read: "ECMA-compliant identifier"). No mentions anywhere
that such identifier would have more format freedom
than any other identifier.
I still think that 3W did a big boo-boo. Trying to satisfy the wildest
naming desires in their DOM/XML models, they neglected the fact that all
this data
will be inevitable treated by some programming language
(PHP, ASP-VScript, Perl, Java, JavaScript etc.)
based on the much more conservative ISO standards.
IMHO it didn't blow up yet just because of some healthy conservatism
of the programmers' community. If you did programming long enough,
it takes some guts and a good shoot of whisky to create an object
_$$_\u0410\u041E_
with a property \041F$$_$
But I'm expecting a lot of fun later when programmers will become more dare
and will try to fully use the given naming freedom.
Still would be interesting to know the Final Right Answer...
I'm afraid only ECMA/ISO guys (or a 3rd-4th grade Computer Science student
who's forced to remember this stuff) would be capable to finalize the
discussion.
I personally don't see what you see in the 11.2.1 of ECMA specs.
IMHO it just says that the Object.Property construct can be presented
in two ways (or a combination of both):
by literals: ObjectName.PropertyName
by expressions: (ExpressionForObjectName)[ExpressionForPropertyName]
The same paragraph states that the final result of evaluation in both cases
is an Identifier (I read: "ECMA-compliant identifier"). No mentions anywhere
that such identifier would have more format freedom
than any other identifier.
I still think that 3W did a big boo-boo. Trying to satisfy the wildest
naming desires in their DOM/XML models, they neglected the fact that all
this data
will be inevitable treated by some programming language
(PHP, ASP-VScript, Perl, Java, JavaScript etc.)
based on the much more conservative ISO standards.
IMHO it didn't blow up yet just because of some healthy conservatism
of the programmers' community. If you did programming long enough,
it takes some guts and a good shoot of whisky to create an object
_$$_\u0410\u041E_
with a property \041F$$_$
But I'm expecting a lot of fun later when programmers will become more dare
and will try to fully use the given naming freedom.
Still would be interesting to know the Final Right Answer...
ECMA 262 Section 7.6 describes the rules that apply whenever the
production - Identifier - is used. However, Section 11.2.1 (Property
Accessors) includes the productions (for bracket notation):-
MemeberExpression [ Expression ]
- and -
CallExpression [ Expression ]
- and the algorithm for resolving these property accessors is:-
<quote cite="ECMA 262 3rd Edition Section 11.2.1 Property Accessors">
...
The production MemberExpression : MemberExpression [ Expression ] is
evaluated as follows:
1. Evaluate MemberExpression.
2. Call GetValue(Result(1)).
3. Evaluate Expression.
4. Call GetValue(Result(3)).
5. Call ToObject(Result(2)).
6. Call ToString(Result(4)).
7. Return a value of type Reference whose base object is
Result(5) and whose property name is Result(6).
The production CallExpression : CallExpression [ Expression ] is
evaluated in exactly the same manner, except that the contained
CallExpression is evaluated in step 1.
</quote>
The result of the - Expression - is used as the property name and the
algorithm does not require that string to conform to the rules for -
Identifier - (it doesn't even check).
So, while production rules that resolve to - Identifier - should produce
errors if the character sequence used does not conform to the rules for
Identifier, ECMA Script does allow properties to be created and read
with _any_ name. If the name does not conform to the rules for
Identifier then it is necessary to use bracket notation to access the
property as that side steps the rules for Identifier.
Therefor a conforming ECMA Script implementation must allow properties
to be created and accessed by _any_ name.
And this is a good thing as even the erroneous interpretation of HTML
CDATA attribute values that attempted to place the NAME and ID
restrictions upon them still allowed character that would not be allowed
in an ECMA Script identifier.
The point at which HTML naming is restricted by the desire to script is
when the attribute values represent integer numbers, but that is more a
consequence of the DOM implementation than ECMA Script as HTML
collections make nodes available as both named properties and as integer
indexed members. So an attempt to read a property of a collection that
is named as an integer number stands a very good chance of returning the
wrong node (or just confusing the DOM implementation).
On the whole, it must be easier to side step the issue by assigning
values to HTML name and ID attributes that are also valid ECMA script
identifiers (indeed that would be the natural thing to do under most
circumstances) but when that is not possible ECMA script is quite
capable of coping with the results (at least under all realistic
circumstances).
Richard.