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
>
>

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
>

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
>