- From: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Date: Mon, 14 Nov 2011 08:08:53 -0800
- To: Yehuda Katz <wycats@gmail.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-script-coord@w3.org, public-webapps <public-webapps@w3.org>
- Message-Id: <F827E408-FDAD-45B3-B9E1-0F9C6ACCFBF5@wirfs-brock.com>
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. Allen
Received on Monday, 14 November 2011 16:09:31 UTC