On Tue, Mar 20, 2012 at 2:53 PM, Allen Wirfs-Brock <[email protected]> wrote: > > On Mar 20, 2012, at 2:10 PM, John J Barton wrote: > >> Object.merge() that merges the own non-function properties as own >> properties, the non-built-in-functions as prototype properties. (a >> compromise of the two common versions of extend, own and 'in' >> versions). > > > and what about own built-in function properties?
Sorry I don't understand what these are. > > We have talked about providing some form of "extend". I guess the talk never led to results in part because there are different versions of extend() in different JS code. > Do you have specific > usage scenarios that support the specific set you rules you just listed. Broadly this operation creates a new object by copying the properties from the argument objects. So the dominant use cases are 1) objects designed to be objects or 2) objects designed to be [[Prototype]]s 3) objects designed to be classes. Merging all of the properties works fine for the 1, the object case. I think the existing practice is designed for 2) [[Prototype]] case for use by developers who simply never mix piles of functions with piles of non-functions. They create .prototype objects by extend() on other .prototype objects. If you get some non-function properties on your [[Prototype]] chain then you can have two different classes of objects writing on each other. If this was not intended, the problem is very confusing and surprising. For 3) you have to apply 1 and 2 to create the data and function properties separately. So to my suggestion then: rather than a merge() or extend() function that treats all the uses cases uniformly, can we have one that addresses the key issues in object formation? As the reader here know, languages with classes typically don't put data properties in the virtual function table. It's not called a virtual *property* table ;-). So the default for an operation to aid in the construction of class-like objects (2 and 3), should be to create an object with data-properties and a [[Prototype]] with functions. If you supply only functions, then you end up with something like Object.create() gives but with multiple inputs (a traits-like design). By simply merging the data properties on the object and the functions onto the [[Prototype]] lots of use cases get covered. If you really wanted data properties on the [[Prototype]], don't use this feature. If you really want to control the [[Prototype]] chain, don't use this feature. Just the simple case. Finally, compare our tools for objects to our tools for Arrays (forEach, et al). Maybe there is some way to solve this problem by combining some primitive operations. jjb _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
