Re: What type should .findAll return

Yehuda Katz
(ph) 718.877.1325


On Sat, Nov 12, 2011 at 11:51 AM, Allen Wirfs-Brock
<allen@wirfs-brock.com>wrote:

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

I think it's worth noting that [[Class]] is actually used by jQuery and
other implementations to identify whether an object is a "real" Array. It
may be the case that we could revisit some of those cases, but the
technique of using [[Class]] to get a less buggy picture of what an object
is (compared to typeof etc.) is pretty common. We use it in SproutCore as
well.

The jQuery.type function:
https://github.com/jquery/jquery/blob/master/src/core.js#L491-495

The class2type map:
https://github.com/jquery/jquery/blob/master/src/core.js#L877-879

toString in that function is declared above as Object.prototype.toString.

That said, of course other aspects of the observed behavior, such as its
exposed methods, matter as well.

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