On 11/13/11 6:10 AM, Allen Wirfs-Brock wrote:
Class related distinctions are covered in the document I reference:
https://docs.google.com/document/d/1sSUtri6joyOOh23nVDfMbs1wDS7iDMDUFVVeHeRdSIw/edit?authkey=CI-FopgC
and are generally secondary issues related to various library routines.
Yes, I'm well aware.
For example, whether JSON outputs the properties of an object using [ ]
or { }. Notation. The only language level semantic specialness of Array
is related to the length invarian
I think you're drawing a distinction between "language level semantics"
and "library routine behavior" which is for practical purposes
irrelevant to everyone outside the ES5 committee...
In practice, at the moment, if you want something that needs to act like
an array as far as a web developer is concerned, it's [[Class]] better
be "Array". In the future, as you note, that might change.
If it isn't the implementation are out of conformance with the standard
that applies to them. That means they are buggy and should be fixed.
The standard does not specify many aspects of implementation behavior,
including but not limited to performance characteristics. However, to
language _consumers_ (e.g. web developers) those
not-specified-in-the-standard aspects are still part of what it means to
"be an array".
It seems to me that there is a serious disconnect here between the way
people are thinking about the standard for arrays and the simple "it
needs to act just like an array in all observable ways" request from web
developers.
For purposes of the ES spec, all that matters is the precise
specification of arrays. For purposes of web developers and web specs
trying to return array-like objects, these things the standard doesn't
care about matter.
It's an expected variance on optimization strategies that I don't think
is particularly relevent to this discussion.
See above. It's 100% relevant to the public-webapps aspects of this
discussion.
BTW, an equally valid
statement would be: the result will have the same performance
characteristics as an actual array in many of todays JITs that optimize
all integer-indexed properties, regardless of whether or not an object
is an actual Array instance.
Sure. So?
-Boris