ES4 draft LAST CALL: Object

Brendan Eich brendan at mozilla.org
Fri Mar 21 10:09:00 PDT 2008


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



More information about the Es4-discuss mailing list