I actually don't expect "mere mortal" ECMAScript programmers to be confused with [[get]] as I won't expect them to have ever been exposed to it. Scanning the rest of the standard ECMAScript objects, the only methods that use a "get" prefix seem to be in Date so this may be some potential for a confusion of conventions there but on the other hand Date seems to largely a world onto itself so I don't know if its usage should really be a concern. A bigger issue may be conventions that have been adopted by the more popular AJAX frameworks, if they are in conflict with the getProperty usage. I admit I'm not real familiar with the detailed APIs of the frameworks but I'm sure somebody here can enlighten me.
Another alternative to "get" would be "reify", eg reifyProperty. My immediate reaction is that it would not be very approachable for unsophisticated users (in other words, most of them). On the other hand, I could argue that if you don't understand what reify means in this context you shouldn't be using the function. And, this is one of the rare case where the dictionary definition fairly precisely corresponds to the technical meaning. This one actually kind of grows on me, but I don't think I could really champion it unless there as a spontaneous outburst of support for it. I could live with lookup, although I think it focuses the meaning on the access process rather than on the result. Another, slightly longer alternative would be "retrieve". Regarding, what getOwnProperty returns, what you currently see in the spec. is probably a bug. My intent was for it to return undefined, although somebody more steeped in JavaScript idioms could convince me that null is more appropriate if that really is the case. The internal function FromPropertyDescriptor probably also needs to return that same value under the appropriate circumstances. Finally, here's another bug: step 3 of Object.getProperty should call [[GetProperty]] rather than [[GetOwnProperty]]. Also step 4 has a "]]" that should be there. -----Original Message----- From: Brendan Eich [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2008 12:37 AM To: Allen Wirfs-Brock Cc: [EMAIL PROTECTED] x-discuss; es4-discuss@mozilla.org es4-discuss Subject: Re: ES3.1 Object static methods rationale document On Jul 16, 2008, at 12:09 AM, Brendan Eich wrote: > On Jul 15, 2008, at 11:50 PM, Brendan Eich wrote: > >> * getProperty and getProperties seem misnamed in light of common >> usage of "get", "[[Get]]", "getProperty", etc. all connoting value- >> getting, not descriptor-getting. getPropertyDescriptor is a bit >> long, but not fatally so. Worth renaming? > > Shorter alternative verbs to "get": lookup, query. The analogy is > lookup : define :: get : put. That was unclear, sorry. I meant to suggest that "lookupProperty" is a shorter alternative to "getPropertyDescriptor". Using "lookup" or "query" relieves the need for "Descriptor" at the end to disambiguate value- from descriptor-getting. So: // returns descriptor if (name in obj), else null or something falsy [1] Object.lookupProperty(obj, name) It's still longer than Object.getProperty, but Object.getProperty seems like a misnomer every time I read it, since it does not do a [[Get]] or [[GetProperty]]. ECMA-262 does not need more overloadings of "get-property" names. Similar comments apply to Object.getOwnProperty. /be [1] The 15 July 2008 draft specifies false, not null, as the return value of Object.getProperty(O, P) when !(P in O) -- is this intended? _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
