On Thu, Oct 6, 2011 at 8:04 PM, Andrew Dupont <mozi...@andrewdupont.net>wrote:
> > (Keep in mind that the 80% use-case for this sort of thing is merging > default options with user-supplied options, at least in the code I write. > That's a simple case that usually involves merging two plain objects without > interesting __proto__ values. That's not to say that we should ignore the > edge cases; but let's just keep them in the proper perspective, and not let > them hold up progress on this front.) > While I agree with Andrew, I wonder if the issue really edge cases. Rather I guess the problem lies in different vision. Object.extend is a bottom up request for functionality; language experts may object that this function is not needed in a proper class-based language? If all the arguments to Object.extend() have prototype Object, then I guess the function is clear. If any of the arguments have other prototypes, we have cases and choices. for..in: all the properties are merged and the final object has prototype Object keys: only the own properties are merged and the final object has prototype Object. proto-power: non-function own properties are merged; function properties create prototype chain, left to right. I suppose all the above is also possible: for..in: Object.flattenProperties() returned a simple object of the for..in kind. keys: Object.ownProperties() returned a simple object of the own properties of the arguments, proto-power: Object.extend() If Object.create() were upgraded to allow a simple object on the second argument (so the result of the above operations can be passed in), then the base Object functions would do a lot of what devs do now with loops over properties. jjb
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
