Re: What type should .findAll return

On Nov 12, 2011, at 10:27 AM, Boris Zbarsky wrote:

> On 11/13/11 6:10 AM, Allen Wirfs-Brock wrote:
>> 
> 
> 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...

It's relevant to this discussion because you have to decide what "web developers" actually mean when they say "Array".  The starting point was that you want NodeArray to be something more than just an Array.  So you have do look at all aspects of Array behavior and decide which you care about.  The language semantic vs library behavior is relevant because it is often much easer for engine implementers to change or extend library behavior then it is to extend language semantics.

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

The most important point is that [[Class]] is neither the only nor the most important distinguishing characteristic of ECMAScript built-in Arrays.  If you are just arguing about [[Class]] you are missing the point.
> 
>> 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.

Such as??  While there are still non-performance aspects  of implementation that are not yet fully specified we are working hard to eliminate (or at least minimize them).  WRT Array, other than performance (including space efficiency) and some aspects of the sort function, what do you think isn't fully specified in ES5.1?  I want to know so I can fix that in "ES6"

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

What are they? Really TC39 doesn't want to have such aspects.

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

"all observable ways" means no methods that aren't already on Array.prototype.  I might think if would be fine for .findAll to just return an actual Array instance.  But others seem to want to augment that behavior so "all observable ways" does not seem to apply.

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

I have to say that I think you are totally mischaracterizing the ES spec and the position of TC39.  I don't understand why?
> 
> 
>> 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.

Still not clear,  are you saying that all implementation are expect to apply the same optimizations?  That clearly isn't the case today.

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

You bought of this implementation specific performance point, for some reason.  I'm just pointing out that your argument goes both ways.  Personally, it sounds to me like design by premature optimization.

Allen

Received on Saturday, 12 November 2011 19:52:15 UTC