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

Lars Hansen lhansen at adobe.com
Sun Apr 13 06:26:43 PDT 2008


IMO the reflection API needs to be able to reveal these things.
So keep an eye out when that spec is released.

--lars 

> -----Original Message-----
> From: es4-discuss-bounces at mozilla.org 
> [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Kris Zyp
> Sent: 12. april 2008 23:14
> To: es4-discuss at mozilla.org
> Subject: lookup attributes/getters/setters (was Re: ES4 draft 
> LAST CALL:Object)
> 
> 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__.
> 
> Thanks,
> Kris
> 
> 
> ----- 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
> >
> > 
> 
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
> 



More information about the Es4-discuss mailing list