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