2011/10/6 John J Barton <johnjbar...@johnjbarton.com> > > > On Wed, Oct 5, 2011 at 10:37 PM, Brendan Eich <bren...@mozilla.com> wrote: > >> On Oct 5, 2011, at 9:02 PM, John J Barton wrote: >> >> > PrototypeJS (and Firebug) pre-date Object.keys() and .hasOwnProperty(), >> >> hasOwnProperty was in ES3 in 1999. PrototypeJS is IIRC 2005-era. Firebug >> is post-y2k. >> >> >> > so their implementation was just what could be done, not what was >> desired. >> >> Seems unhistorical :-|. >> > > Ok, so what is your theory then? > > This code was written by two of the premier JavaScript developers. > > If for..in was intended, then Object.extend should also use for...in. The > experiment has been done, and for..in is the correct semantics. > > If for..in was not intended then what? If developers of this caliber aren't > using the new results here, that's really discouraging. > > Actually there is a third possibility: it really does not matter. The > differences are not significant. >
Actually, I am not sure that having `Object.extend' copy all the enumerable (or all own enumerable) properties by default is a good thing. First, because that copying would be most expensive, and I don't think most usecases would require the parent properties to be copied as well -- not to say it's easier to have conflicts, even if we're talking just about enumerable here, but then, not copying all the own properties, enumerable or not, makes even less sense, imho. Second point being is the expensiveness without bringing in a powerful construct. If you need to grab the properties from an object alongside with its parents, you'd rather use a prototype. And it would be easier in this case if JS supported multiple [[Prototype]]s, like Self does. Object.extend then could be regarded just as a means of copying parent-less objects -- semantic-wise. Third point being that for additional use-cases it's easier to create an abstraction layer that recursively copies the descriptors. About own/own+enumerable, one has to ask what people use these extensions for. Right now, I believe most people are just copying data from one place to another, such that it's okay to copy only enumerable properties. But now, let's take into account that ES5 introduced property descriptors and getters/setters. Also, let's assume people wanted to use these for copying behaviours as well -- ie.: using the objects passed to Object.extend as mixins. In this case, I believe it makes more sense to copy all own descriptors rather than just the enumerable properties, as some behaviours might depend on a property that is there, but was intentionally marked as non-enumerable to avoid problems -- hash implementations could use that. I frankly don't think that these new semantic should be fully backwards compatible with ES3-only code, for I believe ES.next will take a while to be adopted. However, I would like hearing about what people's thoughts are on enumerable+own vs all own property copying without regards to what has been done in pre-ES5 code.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
