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

Adam Barth hk9565 at gmail.com
Mon Apr 14 22:55:13 PDT 2008


We tried to use the reflection API in Firefox and WebKit to determine
if a property had a getter or a setter, but we ended up needing to
know if the reflection API itself had a getter or a setter defined.
Just something to think about when designing the API.

On Sun, Apr 13, 2008 at 6:26 AM, Lars Hansen <lhansen at adobe.com> wrote:
> 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
>  >
>  _______________________________________________
>  Es4-discuss mailing list
>  Es4-discuss at mozilla.org
>  https://mail.mozilla.org/listinfo/es4-discuss
>



More information about the Es4-discuss mailing list