lookup attributes/getters/setters (was Re: ES4 draft LAST CALL: Object)

Kris Zyp kris at sitepen.com
Sat Apr 12 22:14:27 PDT 2008

Do we have any mechanism for detecting if a property is using a 
getter/setter or detecting the attributes of a property? It seems like if we 
can get make getters/setters as properties through object initializers, we 
should be able to detect if a property is using a getter/setter. Also, if we 
can define property attributes through Object.defineProperty, it seems we 
should also be able to detect the attributes of a property. As far as 
attributes, I believe you can use various (ugly) tests to see a property is 
readonly, permanent, and/or enumerable, but it seems reasonable to have a 
complement to defineProperty that could provide this information. In SM (and 
Safari and newer Opera, I assume), you can determine if a property has a 
getter/setter (and get the function) with __lookup{G|S}etter__.


----- Original Message ----- 
From: "Brendan Eich" <brendan at mozilla.org>
To: "Mark S. Miller" <erights at google.com>
Cc: <es4-discuss at mozilla.org>
Sent: Friday, March 21, 2008 11:09 AM
Subject: Re: ES4 draft LAST CALL: Object

> 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
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss

More information about the Es4-discuss mailing list