On Oct 19, 2011, at 1:36 PM, John J Barton wrote: > > > On Wed, Oct 19, 2011 at 11:42 AM, Allen Wirfs-Brock <[email protected]> > wrote: > below > > It isn't clear what you guys are arguing about. > > Under my proposal, > old objects and old code operating upon old objects continue to work as it > always has. > new objects continue to work like old objects unless the new objects have > been explicitly defined to have "collection access behavior" > > You can consider objects with "collection access behavior" to be a new "type" > (I would prefer to say "kind") of object. > > If my proposal, you designate this new kind of object by defining a one of > the collection accessor properties (could be either well know private names > or something like "operator []"). > > Your goal, supporting collections with [] operator, would be widely welcomed > and a big improvement for JavaScript. But your proposal uses new features > unknown to developers and not (as far as I understand) themselves part of the > standard or of implementations. I fear these new features would fail either > here or with developers. Thus I suggested an alternative with the same goal > but independent of other new features. > > Nothing else about my suggestion is important. Reaching the goal of > supporting collections is valuable, and I believe the best chance would not > build on other new features.
Well, this is a (potential) ES.Harmony proposal so dependence upon other ES.Harmony features shouldn't be an issue. However, the only such feature my proposal depends upon is Private Names, which has already been accepted for ES.next. Even that isn't strictly necessary if you are willing to use property names like "operator []" for the element accessor methods. > > > The primitive way to test if an object is a "collection" would be to do a > property existence test on a collection accessor property. > > I think that trying to define a new typeof value to indicate "collection" > would be problematic. What would causes typeof to report "collection"? > > Yes. > > By doing the property existence test? That would generally make typeof a > much more expensive operation and note that the collection accessor methods > could be inherited, so it wouldn't just be a own property check. > I don't know how typeof works, but collection objects would have > isPrototypeOf(Collection) true. The only difference between Object and > Collection would be complete separation of [] and . namespaces. Allowing > operator [] to be redefined is independent of the goal here. Consequently I > would not expect much inheritance. My experience is exactly the opposite, when you have these sorts of capabilities that people in fact do define rich collection libraries that do make extensive use of inheritance in their implementation. > > Note that implicit in this proposal is the assume that there could be many > different collection types. If the identification of a collection was based > upon something other than the existence of certain well known properties then > there would have to be some other way to explicitly brand objects as > collections when they are defined/created. > Yes, just as must be done now for 'function'. Function, (and Array, Date, RegExp, etc.) cannot be "subclassed" in ES <= 5. The reason is because their special behavior depends them being direct instances of specific well-known constructors. This sort of limitation is something we need to eliminate. We don't want to added new kinds of objects that have that limitation. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
