- From: Yehuda Katz <wycats@gmail.com>
- Date: Sat, 12 Nov 2011 12:07:45 -0800
- To: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-script-coord@w3.org, public-webapps <public-webapps@w3.org>
- Message-ID: <CAMFeDTW_uzh11-ki88bEO1vJnjL3zDhOLHhQD2hcbw9L9omczQ@mail.gmail.com>
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 >
Received on Saturday, 12 November 2011 20:08:34 UTC