On Mar 20, 2008, at 6:05 PM, Mark S. Miller wrote: > * I still prefer __defineProperty__ (under whatever name) to be a > static property rather than an instance property, so that an object > can reliably perform this operation on itself without worrying about > whether it is shadowed by an own property of the same name. As an > instance method, to protect against this shadowing, one must instead > write: > > Object.prototype.__defineProperty__.call(this, ...) > > This is so much less convenient than the unsafe > > this.__defineProperty__(...) > > that people will get sloppy. Part of programming language design is to > make the safer way also generally be the easier way. The innumerable > places where > > Object.prototype.hasOwnProperty.call(this, ...) > > were or needed to be written should have already taught these lessons.
I agree completely, based on Narcissus experience -- see: http://lxr.mozilla.org/mozilla/search?string=__defineProperty__ in particular http://lxr.mozilla.org/mozilla/search?string=hasDirectProperty Thanks for pointing this out. The long-standing Mozilla __defineGetter__, __defineSetter__, etc., if they were to be standardized, could also be rephrased as Object "static methods". In ES4 terms these would be final and static, so fixtures. > * I also continue to think that any of the other alternatives for > parameterizing __defineProperty__ were more readable than a bunch of > positional flag parameters whose order will often be mis-remembered. > My favorite remains a C-style or-ing of bit flags, with manifest > constants defining the bits. Agreed again -- Narcissus's __defineProperty__ used dontDelete, readOnly, dontEnum trailing booleans, which at least initially helped by allowing the most common cases to leave off trailing arguments. But I could never remember which was which, reading opaque triples of boolean values in call sites. /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
