On Thu, Oct 6, 2011 at 10:30 AM, Brendan Eich <[email protected]> wrote:
> On Oct 6, 2011, at 8:06 AM, John J Barton wrote: > > On Wed, Oct 5, 2011 at 10:37 PM, Brendan Eich <[email protected]> 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? > > > My point was that your "PrototypeJS and Firebug pre-date .hasOwnProperty()" > chronology was wrong. Object.prototype.hasOwnProperty was around since ES3. > It was not used in Prototype, but on the other hand, the "never extend > Object.prototype" rule was also promulgated. > > True, Array.prototype and other built-in prototypes were extended by > Prototype. So Object.extend(obj, [1, 2, 3]) would copy inherited methods > from Array.prototype to obj, along with properties with keys 0, 1, 2 and > values 1, 2, 3 respectively. > > Given all this, it's not crystal clear what Object.extend is intended to > do. It has definite meaning inherent in its self-hosted implementation, but > we may not want to standardize only that. And private name objects are new > and unforeseen by Prototype's designers. > > > This code was written by two of the premier JavaScript developers. > > > Yes, and we reviewed similar methods a while back from other top JS > libraries. See > > https://mail.mozilla.org/pipermail/es-discuss/2008-July/006709.html > http://ejohn.org/files/object-extend.js > > You're not making an argument from authority, I hope! > > > 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. > > > Perhaps, but we have to consider other parts of the language added since > then. And with the passage of time and the "Object.prototype is verboten" > lesson, we may come to different conclusions from the original authors. > Finally, other libraries differ subtly. > > > If for..in was not intended then what? If developers of this caliber aren't > using the new results here, that's really discouraging. > > > I'm not sure what you mean. Do you mean that someone forgot to use > hasOwnProperty to filter out inherited properties in the for-in loop? Cc'ing > Andrew, he has spoken about this effectively: > > > http://blip.tv/jsconf/jsconf2011-andrew-dupont-everything-is-permitted-extending-built-ins-5211542 > > http://www.slideshare.net/savetheclocktower/everything-is-permitted-extending-builtins > > > Actually there is a third possibility: it really does not matter. The > differences are not significant. > > > That could be. > I guess for..in is close to what a developer wants on average. Typically the RHS is an object literal. If the LHS is a plain object, then for..in is fine. If not then for..in gives a result that works most of the time, as it creates an object with all of the properties you expect to be available on the result. It will trade look time for memory, and in rare cases you get a surprise if you imagined that extend() implemented multiple inheritance. But other choices are similar enough and none will be perfect for all cases. jjb > > /be > > > > jjb > > > >> >> >> > Trait.create() parallels Object.create() and I gather that >> Trait.compose() resembles proposed Object.extend(). I wonder if the >> traits.js 'parallel-universe' could be applied to Trait.resolve(). In my >> experience resolve() isn't needed, but academic work on traits suggests >> otherwise, so it might be a good thing to investigate. >> >> Tom Van Cutsem should weigh in. >> >> /be >> >> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
