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
