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 []"). 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"? 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. 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. Allemn
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
