Re: ES3.1 Object static methods rationale document

[Brendan Eich]

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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: ES3.1 Object static methods rationale document

[Brendan Eich]

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: Two interoperable implementations rule

[Mike Cowlishaw]

Mark wrote:

> Adding decimal to Rhino would presumably build on the BigDecimal 
> class already present in Java. Is Java's BigDecimal class 
> sufficiently conformant to the relevant IEEE spec to support a 
> conformant implementation of the decimal proposed for EcmaScript? 

It follows the same arithmetic rules, but is not a complete implementation 
of IEEE 754 (in particular, it does not have Infinity and NaNs, or 
malleable exponent range limits, and hence its overflow/exception cases 
are different.  Sun were talking of either extending it or providing a 
wrapper class which used it yto provide exact IEEE 754 conformance, but I 
do not know the status of that work item.

> And is the implementation sufficiently independent of the 
> implementation the IBM guys might add to WebKit or Spidermonkey to 
> count as a cross check on the spec? 

Well, I wrote most of the Java 5 extensions to BigDecimal (including the 
MathContext support, etc.), so one might argue that it's not particularly 
independent.  However, it is a completely different implementation, 
historically.

> IBM guys, would you be interested in contributing such a decimal 
implementation to Rhino? 

BigDecimal is 'owned' by Sun, so not really something we could contribute.

Mike





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: ES3.1 Object static methods rationale document

[Douglas Crockford]

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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

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:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 5:39 AM
To: Brendan Eich
Cc: Allen Wirfs-Brock; [EMAIL PROTECTED]; es4-discuss@mozilla.org
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@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: ES3.1 Object static methods rationale document

[Brendan Eich]

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

Re: ES3.1 Object static methods rationale document

[Mark S. Miller]

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
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

A read/write __proto__ that can vanish

[Ingvar von Schoultz]

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

[Brendan Eich]

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 m

Re: ES3.1 Object static methods rationale document

[Brendan Eich]

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

[Ingvar von Schoultz]

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

[Allen Wirfs-Brock]

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

[Brendan Eich]

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

[Brendan Eich]

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

[Allen Wirfs-Brock]

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

[Brendan Eich]

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

[Allen Wirfs-Brock]

(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

[Brendan Eich]

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

[Allen Wirfs-Brock]

-Original Message-
From: Brendan Eich [mailto:[EMAIL PROTECTED]

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?
-

For awhile, defineProperty was called defineOwnProperty but we eventually 
decided all properties are initially defined as own properties so the "Own" was 
redundant.

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. 
However, if that was really important it would probably be better to have a 
built-in function that specifically performed that test without creating a 
descriptor. We may have discussed some more compelling use cases that I don't 
now recall, in which case I'm sure someone will remind me.

In generally, I favor proving just the minimal "spanning set" of functions that 
can be used to build more comprehensive reflection models if desired. If there 
isn't a stronger use case for the version that considers inherited methods I'd 
be happy to eliminate it.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: ES3.1 Object static methods rationale document

[Garrett Smith]

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

[David Flanagan]

Brendan Eich wrote:
> 
> Cool. I'm standing pat on describeProperty.
> 
> /be
> 

[I've removed es3.x-discuss, since I'm not a member]

The verb describe makes this sound like a setter method rather than a 
getter method. That is, describeProperty sounds like a short name for 
setPropertyDescriptor rather than getPropertyDescriptor.

Also, I think there is serious potential for confusion between 
defineProperty and describeProperty.  "Define" and "describe" both begin 
with D and have similar meanings.  Programmers are going to forget which 
method is which.

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.

Frankly, though, I imagine that defining properties will be more common 
than reflecting on them, and I don't see anything wrong with a long name 
that explicitly describes the function: getPropertyDescriptor(), 
lookupPropertyAttributes() or whatever.

David Flanagan
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: ES3.1 Object static methods rationale document

[Garrett Smith]

On Wed, Jul 16, 2008 at 1:41 PM, David Flanagan <[EMAIL PROTECTED]> wrote:
> Brendan Eich wrote:
>>

> Frankly, though, I imagine that defining properties will be more common
> than reflecting on them, and I don't see anything wrong with a long name
> that explicitly describes the function: getPropertyDescriptor(),
> lookupPropertyAttributes() or whatever.
>

I agree. 'getPropertyDescriptor' sounds more descriptive. Allen's doc
calls the return an "attributeDescriptor" but "propertyDescriptor"
seems to be a more descriptive term.

Garrett

>David Flanagan
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: ES3.1 Object static methods rationale document

[Waldemar Horwat]

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

[Waldemar Horwat]

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

[Robert Sayre]

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."
___
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]

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

[Allen Wirfs-Brock]

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

[Allen Wirfs-Brock]

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

[Allen Wirfs-Brock]

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: BOM inside tokens

[Brendan Eich]

Latest news in the bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=430740#c42

Igor wrote:

"So MSIE simply treats BOM as a whitespace for the purpose of  
parsing. Which
suggests to do this in SM to fix the bug: treat BOM as one of Unicode
whitespace characters in the scanner avoiding any character skipping or
patching."

So no security issues with stripping. Another triumph of de-facto  
standard over de-jure.

Pratap got this into ES3.1 drafts already.

/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: ES3.1 Object static methods rationale document

[Maciej Stachowiak]

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

[Allen Wirfs-Brock]

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 rationa

Re: ES3.1 Object static methods rationale document

[Maciej Stachowiak]

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

[Ingvar von Schoultz]

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

[Ingvar von Schoultz]

Brendan Eich wrote:
> 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.
> 

Another idea (with another drum roll): checkProperty. Really short
and accurately descriptive.

-- 
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

[Ingvar von Schoultz]

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

[Allen Wirfs-Brock]

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

[Garrett Smith]

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

[Mark S. Miller]

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

[Kris Zyp]

>> 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

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

Object.create does not support changing the [[Prototype]] of an already 
instantiated object, if that was the question.  It creates a new object with a 
caller specified [[Prototype]] value.  Dynamic modification of an already 
instantiated object's [[Prototype]] is not something that I'm ready to advocate 
for. I believe that the single argument form has the same semantics as 
Crockford's beget function, however it need not be implemented in the same 
manner that Doug uses for beget.

The two argument form also adds the specified own properties to the new object. 
It's probably fair to say that a completely unoptimized implementation of this 
form would be O(n) on the number of properties.  However, I believe that 
Object.create is highly amendable to optimization.  In particular, cases with 
the properties descriptor is specified as an object literal consisting only of 
literal values (including many function expression) might be implemented to 
operate in near constant time.  Note that the same would be true if the second 
argument had been specified as being an object whose properties are to be 
directly copied (essentially making it somewhat more similar to the 
Object.extend function) and the argument is specified using an object literal. 
However, as the use of property descriptors proves the ability to specify the 
attributes of the copied properties in addition to their values.

-Original Message-
From: Kris Zyp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 10:15 PM
To: Brendan Eich; Allen Wirfs-Brock
Cc: [EMAIL PROTECTED]; es4-discuss@mozilla.org
Subject: 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

RE: ES3.1 Object static methods rationale document

[Allen Wirfs-Brock]

The fixture question is a good one, but takes some thought to answer well so 
I'm not going to tackle it until tomorrow.

The other questions are easy:

1) as currently specified, unrecognized properties of a property descriptor are 
ignored.
2) no, in your example, the value of the o1 property of the created object 
would be an object that looks like a property descriptor.

From: Garrett Smith [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 9:17 PM
To: Allen Wirfs-Brock
Cc: es4-discuss@mozilla.org
Subject: 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

[Brendan Eich]

On Jul 16, 2008, at 10:14 PM, Kris Zyp wrote:


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?


ES3.1 draft dated 15-July-08:

15.2.3.6 Object.create ( O [, Properties] )

The create method creates a new object with a specified prototype.  
When the static create method is called, the following steps are taken:


1.If Type(O) is not Object throw a TypeError exception.

2.Create a new object as if by the expression new  
Object() where Object is the standard built-in constructor with that  
name


3.Call the standard built-in function  
Object.defineProperties with arguments Result(2) and Properties.


4.Set the internal [[Prototype]] property of Result 
(2) to Result(1).


5.Return Result(4).




__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?


Object.create allows creation of a new Object instance with a  
designated prototype object initializing [[Prototype]].


/be

___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss