Re: What type should .findAll return

On Monday, November 14, 2011, Allen Wirfs-Brock <allen@wirfs-brock.com>
wrote:
>
> On Nov 12, 2011, at 12:07 PM, Yehuda Katz wrote:
>
> 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.
>
> Those functions are not using "[[Class]]".  They are using the standard
built-in Object.prototype.toString method.  Now, it so happens that the
specification of toString makes use of [[Class]] but that is simply an
artifact of the ES5.1 specification.  It is not a language features.  The
technique that is used to specify toString can be changed without changing
the actual behavior of the toString method.  All that is really required
that existing ES code that depends upon the ES5.1 toString behavior will
continue to work without modification  in future ES implementations that
may use a different specification for toString.  However, it
doesn'tconstrain future code that operates upon new kinds of objects that
didn't exist in the ES5.1 specification.
> BTW, when the ES5.1 spec. talks about objects whose "[[Class]]" has a
specific value. it means precisely such objects as actually specified in
the ES5.1 spec. [[Class]] is not an implementation extension point.  In
particular, ES5.1 clause 8.6.2 says:
>           "The value of the [[Class]] internal property of a host object
may be any String value except one of "Arguments", "Array",..."
> In other words, host object provides (such as a DOM implementation) are
not allowed to define new kinds of objects whose [[Class]] is Array.
> It's fine to want to define a new kind of host object that is
behaviorally very similar (but slight different) from instances of the
built-in Array constructor.  But characterizing such objects by saying they
have [[Class]]=="Array"
>  is a not meaningful from a ES5.1 specification perspective.

I'm fine with any formulation, as long as it gives the correct behaviour in
cases like Array.prototype.concat and Array.isArray.

Do you have suggestions for what to write?

/ Jonas