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

[Robert Sayre-3]

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 <erights@...>:

> On Wed, Jul 16, 2008 at 10:11 AM, Brendan Eich <brendan@...> 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
> Es3.x-discuss@...
> 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@...
https://mail.mozilla.org/listinfo/es4-discuss

[Allen Wirfs-Brock-2]

Working...

-----Original Message-----
From: es3.x-discuss-bounces@... [mailto:es3.x-discuss-bounces@...] On Behalf Of Robert Sayre
Sent: Wednesday, July 16, 2008 2:17 PM
To: Mark S. Miller
Cc: es4-discuss@...; es3.x-discuss@...
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 <erights@...>:

> On Wed, Jul 16, 2008 at 10:11 AM, Brendan Eich <brendan@...> 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
> Es3.x-discuss@...
> 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
Es3.x-discuss@...
https://mail.mozilla.org/listinfo/es3.x-discuss

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

[Brendan Eich-2]

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

[Allen Wirfs-Brock-2]

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:waldemar@...]
Sent: Wednesday, July 16, 2008 2:05 PM
To: Allen Wirfs-Brock
Cc: Douglas Crockford; Brendan Eich; es3.x-discuss@...; es4-discuss@...
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@...
https://mail.mozilla.org/listinfo/es4-discuss

[Allen Wirfs-Brock-2]

Just wait, "reify" may yet end up as the last name standing...

-----Original Message-----
From: es4-discuss-bounces@... [mailto:es4-discuss-bounces@...] On Behalf Of Brendan Eich
Sent: Wednesday, July 16, 2008 2:27 PM
To: David Flanagan
Cc: es4-discuss@... 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@...
https://mail.mozilla.org/listinfo/es4-discuss

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

[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: es4-discuss-bounces@... [mailto:es4-discuss-bounces@...
> ] On Behalf Of Brendan Eich
> Sent: Wednesday, July 16, 2008 2:27 PM
> To: David Flanagan
> Cc: es4-discuss@... 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@...
> https://mail.mozilla.org/listinfo/es4-discuss
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss@...
> https://mail.mozilla.org/listinfo/es4-discuss

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

[Allen Wirfs-Brock-2]

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: es3.x-discuss-bounces@... [mailto:es3.x-discuss-bounces@...] On Behalf Of Robert Sayre
Sent: Wednesday, July 16, 2008 2:17 PM
To: Mark S. Miller
Cc: es4-discuss@...; es3.x-discuss@...
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 <erights@...>:

> On Wed, Jul 16, 2008 at 10:11 AM, Brendan Eich <brendan@...> 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
> Es3.x-discuss@...
> 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
Es3.x-discuss@...
https://mail.mozilla.org/listinfo/es3.x-discuss

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

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

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

[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: es4-discuss-bounces@... [mailto:es4-discuss-bounces@...
>> ] On Behalf Of Brendan Eich
>> Sent: Wednesday, July 16, 2008 2:27 PM
>> To: David Flanagan
>> Cc: es4-discuss@... 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@...
>> https://mail.mozilla.org/listinfo/es4-discuss
>>
>> _______________________________________________
>> Es4-discuss mailing list
>> Es4-discuss@...
>> https://mail.mozilla.org/listinfo/es4-discuss
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss@...
> 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@...
https://mail.mozilla.org/listinfo/es4-discuss

[Allen Wirfs-Brock-2]

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:mjs@...]
Sent: Wednesday, July 16, 2008 5:50 PM
To: Allen Wirfs-Brock
Cc: Robert Sayre; Mark S. Miller; es3.x-discuss@...; es4-discuss@...
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@...
https://mail.mozilla.org/listinfo/es4-discuss

[Garrett]

2008/7/15 Allen Wirfs-Brock <Allen.Wirfs-Brock@...>:
> 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@...
https://mail.mozilla.org/listinfo/es4-discuss

[Mark S. Miller-2]

On Wed, Jul 16, 2008 at 2:17 PM, Robert Sayre <sayrer@...> 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@...
https://mail.mozilla.org/listinfo/es4-discuss

[Kris Zyp-4]

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