Re: What type should .findAll return

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

Received on Saturday, 12 November 2011 18:27:56 UTC