ES3.1 Object static methods rationale document
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 | Next > |
 |
ES3.1 Object static methods rationale document
by Allen Wirfs-Brock-2
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I’ve up loaded to the wiki a new document titled: “Proposed
ECMAScript 3.1 Static Object Functions: Use Cases and Rationale” It’s available as both a pdf and as a Word doc file: _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: ES3.1 Object static methods rationale document
by Brendan Eich-2
::
Rate this Message:
On Jul 15, 2008, at 10:30 PM, Allen Wirfs-Brock wrote:
Hi Allen, Good to see rationales. A few comments: * No rationale responding to the thread containing this message: that questions the wisdom of getPrototypeOf. The other rationales are helpful, the lack of one responding to this public thread questioning essentially the same design element is a lack -- what do you think? * 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? * Did you consider prototype's Object.extend method: Object.extend = function(destination, source) { for (var property in source) destination[property] = source[property]; return destination; }; (see http://www.prototypejs.org/assets/2007/11/6/prototype.js)? It's a commonly encountered "shallow enumerable property clone". John Resig enquired about it being in ES3.1 drafts, but it's not there. Any particular reason why not? /be _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: ES3.1 Object static methods rationale document
by Brendan Eich-2
::
Rate this Message:
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. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: ES3.1 Object static methods rationale document
by Brendan Eich-2
::
Rate this Message:
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@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: ES3.1 Object static methods rationale document
by Douglas Crockford
::
Rate this Message:
Brendan Eich wrote:
> * No rationale responding to the thread containing this message: > > https://mail.mozilla.org/pipermail/es4-discuss/2007-September/001114.html > > that questions the wisdom of getPrototypeOf. The other rationales are > helpful, the lack of one responding to this public thread questioning > essentially the same design element is a lack -- what do you think? The motivation for these methods is to allow Ajax libraries and the Caja runtime to harden the environment. Such a library can use and them remove these methods, disallowing access by guest code. > * Did you consider prototype's Object.extend method: > > Object.extend = function(destination, source) { > for (var property in source) > destination[property] = source[property]; > return destination; > }; Yes we did. _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
RE: ES3.1 Object static methods rationale document
by Allen Wirfs-Brock-2
::
Rate this Message:
I didn't specifically respond to that thread because I wasn't aware of it. I had intended to mention __proto__ as a precedent but it slipped through the cracks.
It's true that __proto__ or getPrototypeOf breaks an object's encapsulation barrier and reveals implementation details that perhaps were intended to be hidden. The same could be said about the proposed getProperty function which, among other things, gives an observer access to the functions that implement a getter/setter property. In general, that's the nature of reflection. Overall, I think that this is a situation that is inherent in our current generation of dynamic languages. They tend to depend upon the use of idioms that require penetration of the encapsulation barrier. Some of the concerns expressed in that thread are address by other aspects of the static Object methods proposal. For example, the integrity of prototype objects can be protected by sealing them in whole or in part to prevent tampering. Also note, that while we support inspection of the prototype value, we don't support modification of it. As Doug implies below, one reason for making these operations "static methods" was to make it easier to control access to them. It you are creating some sort of sandbox, you may not want to make them available within it. That could be taken as a argument in favor of hanging them off of a dedicated global Meta object rather than off of Object. It may be slightly easier to wholesale restrict access to Meta than it would be to restrict access to just these methods while still providing access to the Object constructor. Another already available technique for obtaining the same information in many situations that wasn't mentioned in the thread is to use Object.prototype.isPropertyOf as a probe to discover the prototypes of objects. It isn't something that you would want to do in production code but I don't think that anyone who was trying to crack an application would hesitate from doing. Arguably, some of the need for direct prototype access is alleviated by providing the clone method. However, there are still plenty of other situations where it is useful. I don't agree with Lars' contention that __proto__ and function.caller present the same kind of problem. True, they both break abstraction barriers, but different barriers. __proto__ breaks the object implementation abstraction layer. Function.caller breaks the call stack abstraction. Crossing the object implementation boundary is generally required for defining object abstractions in this language and __proto__ only reveals information that in most cases is already available through other, less direct, means. In contrast, function.caller reveals information about the call stack that is not normally reified in this language or generally needed (those who consider continuations the ultimate programming abstraction may disagree). In summary, not providing reflective access to an object's prototype doesn't really provide any real security, it just makes some useful tasks less convenient. Reverting to barnyard analogies: the barn door is already wide open and we're debating an inch wide "trench" that spans the opening. If we want to keep the horses in we need to think about how to put an iron gate across that gap rather than worrying about the risks of filling in the trench. Allen -----Original Message----- From: Douglas Crockford [mailto:douglas@...] Sent: Wednesday, July 16, 2008 5:39 AM To: Brendan Eich Cc: Allen Wirfs-Brock; es3.x-discuss@...; es4-discuss@... Subject: Re: ES3.1 Object static methods rationale document Brendan Eich wrote: > * No rationale responding to the thread containing this message: > > https://mail.mozilla.org/pipermail/es4-discuss/2007-September/001114.html > > that questions the wisdom of getPrototypeOf. The other rationales are > helpful, the lack of one responding to this public thread questioning > essentially the same design element is a lack -- what do you think? The motivation for these methods is to allow Ajax libraries and the Caja runtime to harden the environment. Such a library can use and them remove these methods, disallowing access by guest code. > * Did you consider prototype's Object.extend method: > > Object.extend = function(destination, source) { > for (var property in source) > destination[property] = source[property]; > return destination; > }; Yes we did. _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: ES3.1 Object static methods rationale document
by Brendan Eich-2
::
Rate this Message:
On Jul 16, 2008, at 5:39 AM, Douglas Crockford wrote:
>> * Did you consider prototype's Object.extend method: >> >> Object.extend = function(destination, source) { >> for (var property in source) >> destination[property] = source[property]; >> return destination; >> }; > > Yes we did. And? The doc gives rationales for design decisions. What's the rationale for leaving Object.extend out? /be _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: ES3.1 Object static methods rationale document
by Mark S. Miller-2
::
Rate this Message:
On Wed, Jul 16, 2008 at 10:11 AM, Brendan Eich <brendan@...> wrote:
And? The doc gives rationales for design decisions. What's the If the document needs to give rationales for leaving out each thing we did not include, it would be quite a long document. What is the argument for adding Object.extend()? A pointer to Resig's message or a prior discussion is an adequate response. -- Cheers, --MarkM _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: ES3.1 Object static methods rationale document
by Brendan Eich-2
::
Rate this Message:
On Jul 16, 2008, at 8:28 AM, Allen Wirfs-Brock wrote:
> I didn't specifically respond to that thread because I wasn't aware > of it. I had intended to mention __proto__ as a precedent but it > slipped through the cracks. No problem. I wanted to point it out so that the rationale doc might include it. > It's true that __proto__ or getPrototypeOf breaks an object's > encapsulation barrier and reveals implementation details that > perhaps were intended to be hidden. The same could be said about > the proposed getProperty function which, among other things, gives > an observer access to the functions that implement a getter/setter > property. In general, that's the nature of reflection. Overall, I > think that this is a situation that is inherent in our current > generation of dynamic languages. They tend to depend upon the use > of idioms that require penetration of the encapsulation barrier. Yeah, I mentioned that in the thread. It's more fundamental than a temporary lack of the current generation of dynamic langauges. Reflection breaks abstraction, removing some free theorems -- news at 11 ;-). > Some of the concerns expressed in that thread are address by other > aspects of the static Object methods proposal. For example, the > integrity of prototype objects can be protected by sealing them in > whole or in part to prevent tampering. This is a good point. SpiderMonkey and Rhino have had Seal APIs for years for this reason (shared prototypes across thread and trust boundaries must be immutable). One feature of both Seal APIs is the ability to seal an entire object graph. This is a sharp tool, since most graphs are fully connected and if you seal the world, life gets boring fast. But it is handy for setting up sealed standard object constructors/prototypes/methods trees with one API call, at the beginning of the world in a throwaway global object that (because of [[Scope]] links) gets sealed too due to the transitive closure. > Also note, that while we support inspection of the prototype value, > we don't support modification of it. I noticed ;-). > As Doug implies below, one reason for making these operations > "static methods" was to make it easier to control access to them. > It you are creating some sort of sandbox, you may not want to make > them available within it. Yes, the static Object method suite is a good idea for that reason, as well as for not intruding on the prototype-delegated property space of all objects. > That could be taken as a argument in favor of hanging them off of > a dedicated global Meta object rather than off of Object. It may > be slightly easier to wholesale restrict access to Meta than it > would be to restrict access to just these methods while still > providing access to the Object constructor. Let's not bring back Meta to ES3.1, it is not wanted in ES4. We should reconcile strict modes too, but that's a different topic -- except insofar as 3.1's strict mode locks down Object.defineProperty, Object.getPrototypeOf, etc. So the host code that removes Object.getPrototypeOf from a guest's sandbox can't be running in strict mode. I'm not suggesting this is a problem, just noting it. > Another already available technique for obtaining the same > information in many situations that wasn't mentioned in the thread > is to use Object.prototype.isPropertyOf as a probe to discover the > prototypes of objects. It isn't something that you would want to do > in production code but I don't think that anyone who was trying to > crack an application would hesitate from doing. Searching the reachable object graph would not only be time- consuming, it could fail to find prototypes that were hidden in disconnected components. The case of an otherwise-unreachable prototype object was discussed in that thread. > Arguably, some of the need for direct prototype access is > alleviated by providing the clone method. However, there are still > plenty of other situations where it is useful. I observe that __proto__ in SpiderMonkey- and Rhino-based JS is mostly used for cases covered by Object.create, with a minority use- case that we've discussed before initializing it to null in object initialisers to make maps (dictionaries). I'm convinced based on this experience that __proto__ is the tempting but wrong low-level "API" to handle these use-cases. I'm in favor of the higher level APIs such as create, clone, and ES4 Map or similar, provided they have the sweet syntax needed to keep kids off the attractive nuisances with which they compete. > Crossing the object implementation boundary is generally required > for defining object abstractions in this language Not generally. Constructor functions and .prototype properties go a long way, and no one has been able to use __proto__ in portable JS on the web, yet life goes on -- and people do define a great many object abstractions in JS libraries. > In summary, not providing reflective access to an object's > prototype doesn't really provide any real security, it just makes > some useful tasks less convenient. I agree with you here in general, and it's good to hear that reflection is not the enemy of "real security". /be _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: ES3.1 Object static methods rationale document
by Brendan Eich-2
::
Rate this Message:
On Jul 16, 2008, at 10:26 AM, Mark S. Miller wrote: On Wed, Jul 16, 2008 at 10:11 AM, Brendan Eich <brendan@...> wrote: The issue of draft ES3.1 adding a great many Object APIs, yet not adding one of the most common APIs from popular Ajax libraries, is legitimate to raise. The answer to my question may not lead to a rationale being added to the document, but there ought to be an answer other than "no" -- or onlookers will rightly suspect that there something is wrong in the reasoning behind the rationales. What is the argument for adding Object.extend()? A pointer to Resig's message or a prior discussion is an adequate response. The argument for Object.extend is similar to the one for Function.bind. Different use-cases, but common re-implementation in real-world code. Both can be built using ES3, but relieving everyone from having to re-invent and re-download these wheels is one of the main purposes of the standard library. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: ES3.1 Object static methods rationale document
by Ingvar von Schoultz
::
Rate this Message:
Brendan Eich wrote:
> 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: I find inspectProperty() a little more descriptive and intuitive. -- Ingvar von Schoultz ------- (My quirky use of capitals in code comes from my opinion that reserved and predefined words should all start with lowercase, and user-defined should all start with uppercase, because this will easily and elegantly prevent a host of name-collision problems when things like programming languages are upgraded with new labels.) _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
RE: ES3.1 Object static methods rationale document
by Allen Wirfs-Brock-2
::
Rate this Message:
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:brendan@...] Sent: Wednesday, July 16, 2008 12:37 AM To: Allen Wirfs-Brock Cc: es3.x-discuss@... x-discuss; es4-discuss@... 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@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: ES3.1 Object static methods rationale document
by Brendan Eich-2
::
Rate this Message:
On Jul 16, 2008, at 11:35 AM, Allen Wirfs-Brock wrote:
> 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". What do you say to Ingvar's suggestion of "inspect"? > Regarding, what getOwnProperty returns, what you currently see in > the spec. is probably a bug. Are you tracking these somewhere? I think bugs.ecmascript.org is a fine way to keep trac(k). :-) > 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. JS has two bottoms: null means no object and undefined means no value, so for this kind of "descriptor object if property exists, else bottom" API, null is better. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: ES3.1 Object static methods rationale document
by Brendan Eich-2
::
Rate this Message:
On Jul 16, 2008, at 11:44 AM, Brendan Eich wrote:
> On Jul 16, 2008, at 11:35 AM, Allen Wirfs-Brock wrote: > >> 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". > > What do you say to Ingvar's suggestion of "inspect"? Or (drum roll) "describe": describeProperty, which returns a property descriptor. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
RE: ES3.1 Object static methods rationale document
by Allen Wirfs-Brock-2
::
Rate this Message:
(I'm not going to get you to take the bait on "reify", am I?)
I think I like "describe" better than "inspect" for no particularly tangible reason, although it does have more characters. I generally find the Thesaurus a useful tool in this process and it turned up "depict" which is shorter but also seems to capture the same core distinction as "describe". I think that the currently named getOwnProperty is more fundamental than getProperty so in considering length we should probably use the former as our benchmark. BTW, I'm open to arguments that we don't really need getProperty (as long as getPrototypeOf is kept). (Oh shit ... do we need to rename that one, too??) I think we've pretty much covered the "name space" and would be content, at this point, to sit back for a few days and see if anybody else is brave enough to argue for one name over another. If not I think we can reach agreement on one of these that we have been discussing. Allen -----Original Message----- From: Brendan Eich [mailto:brendan@...] Sent: Wednesday, July 16, 2008 11:52 AM To: Allen Wirfs-Brock Cc: es3.x-discuss@... x-discuss; es4-discuss@... es4-discuss Subject: Re: ES3.1 Object static methods rationale document On Jul 16, 2008, at 11:44 AM, Brendan Eich wrote: > On Jul 16, 2008, at 11:35 AM, Allen Wirfs-Brock wrote: > >> 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". > > What do you say to Ingvar's suggestion of "inspect"? Or (drum roll) "describe": describeProperty, which returns a property descriptor. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: ES3.1 Object static methods rationale document
by Brendan Eich-2
::
Rate this Message:
On Jul 16, 2008, at 12:31 PM, Allen Wirfs-Brock wrote:
> (I'm not going to get you to take the bait on "reify", am I?) (no way! ;-) > I think I like "describe" better than "inspect" for no particularly > tangible reason, although it does have more characters. I generally > find the Thesaurus a useful tool in this process and it turned up > "depict" which is shorter but also seems to capture the same core > distinction as "describe". Length is less of an issue, given the rationale doc's points in favor of "keyword parameters via object literals", etc. > I think that the currently named getOwnProperty is more fundamental > than getProperty so in considering length we should probably use > the former as our benchmark. BTW, I'm open to arguments that we > don't really need getProperty (as long as getPrototypeOf is kept). > (Oh shit ... do we need to rename that one, too??) No, that's a value-get, not a descriptor-get. But you raise a good point: defineProperty creates an own property. Is there really a need for getProperty as drafted? If not, I'd favor making describeProperty return null if the named property is not "own", but in a prototype. What are use-cases for getProperty as distinct from getOwnProperty? > I think we've pretty much covered the "name space" and would be > content, at this point, to sit back for a few days and see if > anybody else is brave enough to argue for one name over another. If > not I think we can reach agreement on one of these that we have > been discussing. Cool. I'm standing pat on describeProperty. /be _______________________________________________ Es4-discuss mailing list |
