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:kris at sitepen.com]
Sent: Wednesday, July 16, 2008 10:15 PM
To: Brendan Eich; Allen Wirfs-Brock
Cc: es3.x-discuss at mozilla.org; es4-discuss at 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