On Wed, Oct 19, 2011 at 11:42 AM, Allen Wirfs-Brock <[email protected]>wrote:
> below > > On Oct 19, 2011, at 10:44 AM, John J Barton wrote: > > > > On Wed, Oct 19, 2011 at 10:27 AM, Axel Rauschmayer <[email protected]>wrote: > >> Problem: How do you invoke methods on table? >>> >> >> table.tellAxel = function() {alert('here is a method call');}; >> table['tellAxel'] = function() {alert('here is a function entry");}; >> table.tellAxel(); // here is a method call >> table['tellAxel'].apply(null,[]); // here is a function entry >> >> >>> Using AWB’s terminology, accessing properties is part of the program >>> definition domain, accessing collection elements is part of the application >>> data domain. And it’s better not to mix the two. >>> >> >> Yes, that is exactly the point. >> >> >> So you are arguing in favor of approach #1, right? >> > > No, I am arguing against changing the meaning of [] on 'object'. > > >> Then I would make “your” Map a subtype of Object. typeof is currently best >> limited to primitives (and to distinguishing them from objects), so >> introducing a new result would suggest adding a new primitive. >> > > No, the goal is exactly to distinguish collections from objects. > > >> But I don’t think that is necessary: Once the semantics of [] have been >> changed in accordance with approach #1 then you can just write a library >> that provides Maps and other collections. >> > > We disagree. I don't want to fix old code, it works, let it be. I want new > code to have a great new option. New tools can migrate developers to new > options. And these things can happen in our lifetime. > > jjb > > > 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. > > 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. 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'. jjb > > Allemn > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
