Re: ES3.1 Object static methods rationale document
On Jul 15, 2008, at 10:30 PM, Allen Wirfs-Brock wrote:
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:
http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%
3Aes3.1_proposal_working_draftcache=cachemedia=es3.1:rationale_for_e
s3_1_static_object_methods.pdf
http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%
3Aes3.1_proposal_working_draftcache=cachemedia=es3.1:rationale_for_e
s3_1_static_object_methods.doc
Hi Allen,
Good to see rationales. A few comments:
* 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?
* 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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
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
Re: ES3.1 Object static methods rationale document
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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
A read/write __proto__ that can vanish
Some people yearn hotly for __proto__, preferrably writable if
at all possible, while others point to problems with security
and software privacy.
I get the impression that this could be solved by adding a fourth
flag among the property flags Enumerable, Writable and Flexible.
There might be a flag called Visible, so you could make __proto__
apparently vanish by setting Visible to false.
As an added bonus, this solution would let code hide the prototype
property on constructors if desired.
Personally I'd love to see it defined in such a way that I could
set prototype inheritance in a simple, straightforward way at the
beginning of a constructor function:
function $MyConstructor()
{ this.proto = MySuperInstance;
// Here you can hide proto if desired.
...
}
If a visible proto is standardized, the name should be proto, not
__proto__, in my opinion. The underscores indicate nonstandard.
--
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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
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
Re: ES3.1 Object static methods rationale document
On Jul 16, 2008, at 10:26 AM, Mark S. Miller wrote: On Wed, Jul 16, 2008 at 10:11 AM, Brendan Eich [EMAIL PROTECTED] wrote: And? The doc gives rationales for design decisions. What's the rationale for leaving Object.extend out? If the document needs to give rationales for leaving out each thing we did not include, it would be quite a long document. It's pretty long already, yet it dotes on some issues that are less relevant than Object.extend, as demonstrated by all the Ajax code that uses Object.extend but does without, e.g., Object.getPrototypeOf (or __proto__). Do what you want with the doc, but please don't dismiss particular requests for rationales with general fretting about document length. 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. https://bugzilla.mozilla.org/show_bug.cgi?id=433351 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@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
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@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES3.1 Object static methods rationale document
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
Re: A read/write __proto__ that can vanish
On Jul 16, 2008, at 10:29 AM, Ingvar von Schoultz wrote: Some people yearn hotly for __proto__, preferrably writable if at all possible, while others point to problems with security and software privacy. I wrote recently that __proto__ should be viewed as call/cc without macros for common use-case (and average users) -- too sharp and low- level a tool for a language like JS. I get the impression that this could be solved by adding a fourth flag among the property flags Enumerable, Writable and Flexible. There might be a flag called Visible, so you could make __proto__ apparently vanish by setting Visible to false. There's no point in Visible if the property could be deleted altogether. What would be the difference? Note that a proto or __proto__ property reflecting [[Prototype]] is *not* the same as the internal [[Prototype]] property, which would always be visible in the sense of checked by [[Get]], [[Put]], etc. We should not add property attributes that can mutate lightly. The motivation for __proto__ is suspect (I argue, base on our experience -- and I perpetrated __proto__ a long time ago). The need for Visible is non-existent IMHO, while the costs and ramifications of another single-bit attribute, one that causes the property to appear to be deleted, are undesirable. Visibility control over names is an important topic, but it can't be served by a single-bit attribute. ES4 as proposed has namespaces to serve (among other use-cases) the cheap and easily expressed private members use-case. That's not this __proto__ case, which anyway depends on a suspect predicate (the need for __proto__). Better to settle the predicate issue first, and avoid adding general mechanism prematurely. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
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@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: A read/write __proto__ that can vanish
Personally, I don't that the internal [[Prototype]] property should reify as
an actual property of the object. It's really a more fundamental aspect of
objectness than regular properties. From that perspective, if you want to
control access to it, it should probably be done as a flag on the object
itself, much as the ES3.1 proposal does with the [[Extensible]] property.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ingvar von
Schoultz
Sent: Wednesday, July 16, 2008 10:29 AM
To: [EMAIL PROTECTED]; es4-discuss@mozilla.org
Subject: A read/write __proto__ that can vanish
Some people yearn hotly for __proto__, preferrably writable if
at all possible, while others point to problems with security
and software privacy.
I get the impression that this could be solved by adding a fourth
flag among the property flags Enumerable, Writable and Flexible.
There might be a flag called Visible, so you could make __proto__
apparently vanish by setting Visible to false.
As an added bonus, this solution would let code hide the prototype
property on constructors if desired.
Personally I'd love to see it defined in such a way that I could
set prototype inheritance in a simple, straightforward way at the
beginning of a constructor function:
function $MyConstructor()
{ this.proto = MySuperInstance;
// Here you can hide proto if desired.
...
}
If a visible proto is standardized, the name should be proto, not
__proto__, in my opinion. The underscores indicate nonstandard.
--
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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
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@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES3.1 Object static methods rationale document
(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:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2008 11:52 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 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@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
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 Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
On Wed, Jul 16, 2008 at 1:16 PM, Allen Wirfs-Brock [EMAIL PROTECTED] wrote: -Original Message- From: Brendan Eich [mailto:[EMAIL PROTECTED] Right now, the best I can come up with is that it should be a relatively efficient way to test for the existence of a possibly inherited property. The in operator tests for the existence of a possibly inherited property. var hasProp = (p in o); Garrett ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
Allen Wirfs-Brock wrote: 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. On the other hand, providing reflective access to an object's prototype is harmful to compatibility because it prevents implementations from introducing intermediate prototypes without breaking the web. Consider the example of having just Numbers and later compatibly introducing more specific subkinds of Numbers. Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: A read/write __proto__ that can vanish
Ingvar von Schoultz wrote: Some people yearn hotly for __proto__, preferrably writable if at all possible, while others point to problems with security and software privacy. I get the impression that this could be solved by adding a fourth flag among the property flags Enumerable, Writable and Flexible. There might be a flag called Visible, so you could make __proto__ apparently vanish by setting Visible to false. Adding switches like this is making code too complicated and will result in plenty of arguments about whether a particular class should have the switch turned on or off. Often the classes you want to use will have it set the wrong way, leading to more balkanization of libraries. In the committee we've already spent too much time discussing which properties should be enumerable, dontDelete, etc., and we still get those wrong at times. Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
On Jul 16, 2008, at 1:41 PM, David Flanagan wrote: Brendan, I think you were correct when you originally wrote: lookup : define :: get : put. I think that lookupProperty is much nicer than describeProperty, since lookup captures the getter nature of the method in a way that describe does not. Connotations are many, ambiguity without a noun phrase (not just overloaded old property) saying what's being got or described or looked up is inevitable. This means the stolid, safe name getPropertyDescriptor is least likely to confuse. I see what you mean about describe in the context of setting a description (depict in a graphics context is problematic too) -- thanks. Thesaurus doesn't include mental concept filtering, dammit. I'm sure we'll get this right, but I'm also pretty sure getProperty isn't the droid we are seeking. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES3.1 Object static methods rationale document
The ES3 spec already specifies the specific prototype of each built-in object and their instances. However, when it comes to implementing built-in objects or for that matter user defined objects there is nothing that prevents an implementation from using invisible intermediate prototypes for whatever purposes it finds useful. Those, of course, would not be visible to a getPrototypeOf function. Penetrating an implementation encapsulation barrier whether at the engine, library, or framework level always carries with it the risk of introducing implementation dependencies. That doesn't mean there aren't good reasons for doing so, you just better know what you're doing and use appropriate care. The static Object methods are intend for use by people who know what they are doing. Certainly, there is an attractive nuisance factor that will get some people into trouble. If you file off all the points and dull all the edges you usually do end up with a very useful tool. -Original Message- From: Waldemar Horwat [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2008 2:05 PM To: Allen Wirfs-Brock Cc: Douglas Crockford; Brendan Eich; [EMAIL PROTECTED]; es4-discuss@mozilla.org Subject: Re: ES3.1 Object static methods rationale document Allen Wirfs-Brock wrote: 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. On the other hand, providing reflective access to an object's prototype is harmful to compatibility because it prevents implementations from introducing intermediate prototypes without breaking the web. Consider the example of having just Numbers and later compatibly introducing more specific subkinds of Numbers. Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES3.1 Object static methods rationale document
Working... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Sayre Sent: Wednesday, July 16, 2008 2:17 PM To: Mark S. Miller Cc: es4-discuss@mozilla.org; [EMAIL PROTECTED] Subject: Re: ES3.1 Object static methods rationale document Maybe someone could just give the rationale for leaving out Object.extend? Douglas Crockford wrote that it was considered, but I'm confused since it looks like you haven't even seen a proposal, and didn't participate in the discussion to exclude it. - Rob 2008/7/16 Mark S. Miller [EMAIL PROTECTED]: On Wed, Jul 16, 2008 at 10:11 AM, Brendan Eich [EMAIL PROTECTED] wrote: And? The doc gives rationales for design decisions. What's the rationale for leaving Object.extend out? 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 ___ Es3.x-discuss mailing list [EMAIL PROTECTED] https://mail.mozilla.org/listinfo/es3.x-discuss -- Robert Sayre I would have written a shorter letter, but I did not have the time. ___ Es3.x-discuss mailing list [EMAIL PROTECTED] https://mail.mozilla.org/listinfo/es3.x-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES3.1 Object static methods rationale document
Just wait, reify may yet end up as the last name standing... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich Sent: Wednesday, July 16, 2008 2:27 PM To: David Flanagan Cc: es4-discuss@mozilla.org es4-discuss Subject: Re: ES3.1 Object static methods rationale document On Jul 16, 2008, at 1:41 PM, David Flanagan wrote: Brendan, I think you were correct when you originally wrote: lookup : define :: get : put. I think that lookupProperty is much nicer than describeProperty, since lookup captures the getter nature of the method in a way that describe does not. Connotations are many, ambiguity without a noun phrase (not just overloaded old property) saying what's being got or described or looked up is inevitable. This means the stolid, safe name getPropertyDescriptor is least likely to confuse. I see what you mean about describe in the context of setting a description (depict in a graphics context is problematic too) -- thanks. Thesaurus doesn't include mental concept filtering, dammit. I'm sure we'll get this right, but I'm also pretty sure getProperty isn't the droid we are seeking. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
On Jul 16, 2008, at 2:36 PM, Allen Wirfs-Brock wrote: Just wait, reify may yet end up as the last name standing... Methods don't reify things, the language definition does. Property descriptors are reified in ES3.1 whether or not you ever call the method. I think getPropertyDescriptor is the best name suggested so far, it has no chance of being confused for a method that would get the property value, and it does not use obscure CS jargon in an incorrect way. I don't think brevity is critical for these metaprogramming/ reflection type methods - they are not the kind of thing that will be commonly used by most programmers. Mostly they will be used by frameworks such as Ajax libraries or secure language subsets. Regards, Maciej -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Brendan Eich Sent: Wednesday, July 16, 2008 2:27 PM To: David Flanagan Cc: es4-discuss@mozilla.org es4-discuss Subject: Re: ES3.1 Object static methods rationale document On Jul 16, 2008, at 1:41 PM, David Flanagan wrote: Brendan, I think you were correct when you originally wrote: lookup : define :: get : put. I think that lookupProperty is much nicer than describeProperty, since lookup captures the getter nature of the method in a way that describe does not. Connotations are many, ambiguity without a noun phrase (not just overloaded old property) saying what's being got or described or looked up is inevitable. This means the stolid, safe name getPropertyDescriptor is least likely to confuse. I see what you mean about describe in the context of setting a description (depict in a graphics context is problematic too) -- thanks. Thesaurus doesn't include mental concept filtering, dammit. I'm sure we'll get this right, but I'm also pretty sure getProperty isn't the droid we are seeking. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES3.1 Object static methods rationale document
As far as I can recall, we didn't discuss a specific formulation that corresponds to Object.extend but we have considered (and arguably provided) pretty much equivalent functionality in our proposal. I assume that at least Doug, Adam, or Kris were specifically aware of Object.extend and would have broad it up if it was relevant. One reason, it probably wasn't was that the starting point of our design was the full reification and control of properties and their attributes rather than just copying properties. By the time we got around to cloning/copying issues we already had establish some core elements of our overall design. Doing a bit of search I've found several different variants of the extend function. Some are defined on Object, some on Object.prototype. Some use a single source object and some use multiple source objects. What they all seem to have in common is that they copy the enumerable methods from one (or more) object to another. The most common use case seems to be the one where the target object is a newly instantiated object without any properties of its own. That use case (at least for variants of extend that only take a single source object) is most directly supported by the Object.clone function in our proposal. However, Object.clone is defined to be a more comprehensive object duplication process than is performed by extend. It duplicates all own properties and their attributes and any internal properties such as its [[Value]] property if it has one. I have personally considered whether there should be some sort of mechanism to filter the properties copied by Object.clone. For example, you might only copy non getter/setter properties, or only enumerable properties, or perhaps filter out ReadOnly properties. However, I never proposed any of these for the ES3.1 spec. because I have yet to find a use case that was sufficiently compelling or pervasive enough to justify making the interface to Object.clone more complex (in contrast, see the explanation in the rationale document for why we added a second argument to Object.create). If you want to do that sort of filtering you can do it using Object.wontbecalledgetProperty and Object.defineProperty. If you just want a fast and comprehensive copy use Object.clone. The other obvious use case would seem to be adding some mix-in behavior to an object (some of the descriptions of extend on the web call this inheritance but it's not how I'd use that term). This use case is fairly directly supported by Object.defineProperties although it is formulated somewhat differently. As I mention in our rationale document, this design isn't just a set of individual functions but an attempt at a unified design where we have tried to distribute the functional elements across of set of related functions that often have multiple uses. Object.extend is a fine function, particular when viewed from the perspective of what can be accomplished using the available ES3 APIs. However, it isn't something I would simply add as whole cloth to the set of functions we have already worked out. That would mostly just added redundant functionality and in a manner that wasn't particularly consistent with the other functions we have defined. Instead, if we added it we would potentially refactor the functionality of all of the proposed static Object functions to make them stand together as a unit. I'd be happy to discuss additional use cases to see try to see if we can find any significant hole in our proposal. Finally, I want to say that my approach to a situation like this where there appears to be multiple versions of a similar but not identical function is not necessarily to pick one and make everybody else conform. Instead, I like to approach the problem from the perspective of what would have made these various functions unnecessary and what primitives would have been useful in implementing the assorted variations. If I can provide that then future users are unlikely to need to use the old forms and existing user can migrate by continuing to use their old API but perhaps reimplementing them using the new primitives. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Sayre Sent: Wednesday, July 16, 2008 2:17 PM To: Mark S. Miller Cc: es4-discuss@mozilla.org; [EMAIL PROTECTED] Subject: Re: ES3.1 Object static methods rationale document Maybe someone could just give the rationale for leaving out Object.extend? Douglas Crockford wrote that it was considered, but I'm confused since it looks like you haven't even seen a proposal, and didn't participate in the discussion to exclude it. - Rob 2008/7/16 Mark S. Miller [EMAIL PROTECTED]: On Wed, Jul 16, 2008 at 10:11 AM, Brendan Eich [EMAIL PROTECTED] wrote: And? The doc gives rationales for design decisions. What's the rationale for leaving Object.extend out? If the document needs to give rationales for leaving
Re: ES3.1 Object static methods rationale document
On Jul 16, 2008, at 4:10 PM, Allen Wirfs-Brock wrote: The most common use case seems to be the one where the target object is a newly instantiated object without any properties of its own. That use case (at least for variants of extend that only take a single source object) is most directly supported by the Object.clone function in our proposal. However, Object.clone is defined to be a more comprehensive object duplication process than is performed by extend. It duplicates all own properties and their attributes and any internal properties such as its [[Value]] property if it has one. 1) It seems like Object.clone as you have described it is not suitable for the mixin type use case where an object gets properties/methods from two others. Or at least, it only does half the job. 2) Is Object.clone expected to work on host objects (in particular DOM- related objects)? I think thorough cloning of all state is not a practical semantic in that case, and would be a very large burden on implementations. In the case of some classes (Window or Location for instance) allowing true cloning might even be a security risk. And if it does not support host objects then copying internal state like the [[Value]] or [[Class]] property for ES standard object types will be more confusing than helpful. Regards, Maciej ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: A read/write __proto__ that can vanish
Brendan Eich wrote:
There's no point in Visible if the property could be deleted
altogether. What would be the difference?
Oops! Sorry! Lacking low-level insight I didn't think of that.
So my idea has no bearing at all on the inherent problems, much
less solved them. Too bad.
That's not this __proto__ case, which anyway
depends on a suspect predicate (the need for __proto__). Better to
settle the predicate issue first, and avoid adding general mechanism
prematurely.
I think the only situation where I repeatedly feel a real,
serious need for something like a writable __proto__ is
the one I showed. Specifying inheritance is too spread out
and too intricate. Most of all I want the constructor to
define its own inheritance, not some outside code. Having
to set .prototype in an unrelated expression outside, with
the constructor reduced to a powerless bystander, feels like
I'm writing a goto. It's too unstructured.
Is your objection to __proto__ similar to this? Is __proto__
an inheritance goto? If that's the kind of problem it creates
I agree that it doesn't belong in this language.
If that's the case, would a writable __proto__ become well-
structured if it could be accessed only from inside the
constructor, and not by any other code? That's the only
way I'd use it anyway.
I'd love to have constructors that could write to their
[[Prototype]]. But if that isn't possible I'd be almost
as happy if we simply had the option to set both the
prototype and its constructor property in one compound
statement:
function $MyConstructor()
prototype MySuperInstance
{ ...
}
For me this would generally be the best arrangement, and
I suppose it's the same for most people. Not having analyzed
all the details, it /seems/ to me that the ideal would be
that the above syntax lock and hide [[Prototype]], while a
different syntax for exotic use would allow the constructor
added freedom.
--
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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
Although I agree that brevity isn't very important here, still
here's a shorter variation on the same names:
Object.getDescriptor (MyObject, MyName);
Object.setDescriptor (MyObject, MyName, {enumerable: false});
Ingvar
Maciej Stachowiak wrote:
On Jul 16, 2008, at 2:36 PM, Allen Wirfs-Brock wrote:
Just wait, reify may yet end up as the last name standing...
Methods don't reify things, the language definition does. Property
descriptors are reified in ES3.1 whether or not you ever call the
method.
I think getPropertyDescriptor is the best name suggested so far, it
has no chance of being confused for a method that would get the
property value, and it does not use obscure CS jargon in an incorrect
way. I don't think brevity is critical for these metaprogramming/
reflection type methods - they are not the kind of thing that will be
commonly used by most programmers. Mostly they will be used by
frameworks such as Ajax libraries or secure language subsets.
Regards,
Maciej
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
] On Behalf Of Brendan Eich
Sent: Wednesday, July 16, 2008 2:27 PM
To: David Flanagan
Cc: es4-discuss@mozilla.org es4-discuss
Subject: Re: ES3.1 Object static methods rationale document
On Jul 16, 2008, at 1:41 PM, David Flanagan wrote:
Brendan, I think you were correct when you originally wrote:
lookup : define :: get : put.
I think that lookupProperty is much nicer than describeProperty,
since
lookup captures the getter nature of the method in a way that
describe does not.
Connotations are many, ambiguity without a noun phrase (not just
overloaded old property) saying what's being got or described
or looked up is inevitable. This means the stolid, safe name
getPropertyDescriptor is least likely to confuse.
I see what you mean about describe in the context of setting a
description (depict in a graphics context is problematic too) --
thanks. Thesaurus doesn't include mental concept filtering, dammit.
I'm sure we'll get this right, but I'm also pretty sure getProperty
isn't the droid we are seeking.
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
--
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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
RE: ES3.1 Object static methods rationale document
Object.clone is really just what is sometimes called a shallow copy. I would
expect it to be most commonly used to make copies of objects that are mostly
statefull, not for moving behavior around.
If you have one or more mix-ins that you want to directly add to a objects, I
would use defineProperties. Generally, one defineProperties per mixin although
you could also use defineProperties to compose a number of such mix-ins into a
composite which you then injected into objects as a unit.
However, I don't think I would normally want to do a lot of that sort of
property injection, at least not for behavioral properties. (augmenting host
objects is probably an exception to that) The cheapest way to provide behavior
to multiple objects should be via their prototype chains. Object.create make
it easy to do that and it can also be used to linearize a set of mix-ins into a
prototype chain. For example, assume that a,b, and c are property set
descriptors for 3 mix-ins. You can linearize them by:
var newParent = Object.create(Object.create(Object.create({},c),b),a);
and then create instances with that behavior by doing something like:
return Object.create(newParent,perInstanceProperties)
The Es3.1 draft currently says that the effect of Object.clone is
implementation defined for host objects. That's because I've had it beat into
me (mostly by people on this list) that host objects get to set their own rules
and that there is nothing we can do about it. Personally, I'd be more demanding
upon the integration of host objects but, as I can imagine Brendan saying,
that ship sailed ten years ago.
-Original Message-
From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 5:50 PM
To: Allen Wirfs-Brock
Cc: Robert Sayre; Mark S. Miller; [EMAIL PROTECTED]; es4-discuss@mozilla.org
Subject: Re: ES3.1 Object static methods rationale document
On Jul 16, 2008, at 4:10 PM, Allen Wirfs-Brock wrote:
The most common use case seems to be the one where the target object
is a newly instantiated object without any properties of its own.
That use case (at least for variants of extend that only take a
single source object) is most directly supported by the Object.clone
function in our proposal. However, Object.clone is defined to be a
more comprehensive object duplication process than is performed by
extend. It duplicates all own properties and their attributes and
any internal properties such as its [[Value]] property if it has one.
1) It seems like Object.clone as you have described it is not suitable
for the mixin type use case where an object gets properties/methods
from two others. Or at least, it only does half the job.
2) Is Object.clone expected to work on host objects (in particular DOM-
related objects)? I think thorough cloning of all state is not a
practical semantic in that case, and would be a very large burden on
implementations. In the case of some classes (Window or Location for
instance) allowing true cloning might even be a security risk. And if
it does not support host objects then copying internal state like the
[[Value]] or [[Class]] property for ES standard object types will be
more confusing than helpful.
Regards,
Maciej
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
2008/7/15 Allen Wirfs-Brock [EMAIL PROTECTED]:
I've up loaded to the wiki a new document titled: Proposed ECMAScript
3.1
Static Object Functions: Use Cases and Rationale
A couple of questions for you:
My first question: How does an ES3.1 sealed object relate to fixtures?
__| ES 3.1 __| ES4___
Sealed object | Object.seal | fixture (var)
My second question is about Object.create. Object.create() mixes adding a
prototype to an object with a
specialized context where the (verbose) object literal contains certain
property names, such as value, take on contextual meaning to the
property.
1. What happens when an unrecognized property is in the descriptor? (1)
2. Is it only possible to define attributes on the top level? (2)
(1)
Object.create(myProto, {
method3: {
enumerable: false, writable: false,
novalue : true // no [[value]] + custom attribute
},
,method2: undefined
});
(2) Object.create(myProto, {
o1: {
enumerable: true, writable: false,
value : {
enumerable : false,
value : undefined
}
}
});
Garrett
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
On Wed, Jul 16, 2008 at 2:17 PM, Robert Sayre [EMAIL PROTECTED] wrote: Maybe someone could just give the rationale for leaving out Object.extend? Douglas Crockford wrote that it was considered, but I'm confused since it looks like you haven't even seen a proposal, and didn't participate in the discussion to exclude it. I do not remember any discussion of Object.extend(). However, I have not attended all ES3.1 discussions. -- Cheers, --MarkM ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
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 am curious how Object.create covers this __proto__ use case of making objects with a defined proto. Doesn't Object.create create a new object and copy properties over? __proto__ allows objects with existing properties to have their proto defined in constant time, but isn't Object.create still O(n), with n being the number of properties? Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
