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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Kris Zyp > > Sent: 12. april 2008 23:14 > > To: [email protected] > > 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" <[EMAIL PROTECTED]> > > To: "Mark S. Miller" <[EMAIL PROTECTED]> > > Cc: <[email protected]> > > 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 > > > [email protected] > > > https://mail.mozilla.org/listinfo/es4-discuss > > > > > > > > > > _______________________________________________ > > Es4-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es4-discuss > > > _______________________________________________ > Es4-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es4-discuss > _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
