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
