Object.prototype.clone
On 10/21/07, Peter Michaux <petermichaux at gmail.com> wrote:
Hi,
Is there a plan for a "clone" function in ES4?
Object.prototype.clone = function() { function F() {} F.prototype = o; return new F(); };
The earliest reference I have found to this function is a post by Lasse Reichstein Nielsen in 2003 on comp.lang.javascript
groups.google.com/group/comp.lang.javascript/msg/5d06e72e55d5bf11
In the past year this function has been evangelized by Douglas Crockford.
I had the misfortune of working on code that uses this pattern while at Yahoo. Since Yahoo pretty much shuns testing and my boss didn't really like me refactoring code, my debugging skills improved. What mess of code. I still remember the code object. 1100+ line module pattern
YAHOO.mst.app.code = (function(){ // 1100+ lines...
return {
}; })_
The guys would sometimes get confused and reassign the namespace to a variable, too. YAHOO.namespace("mst.app.code"); YAHOO.mst.app.code.getGlobal = function(k){};
YAHOO.mst.app.code = (function(){ // uh-oh, what happened to getGlobal?
});
An interesting device, hard to debug, confuses less-skilled programmers, usually relies on too much anon functions/constructors. Increases scope chain.
I don't see the part about clone. Cloning brings up the issue of "how deep".
Given the idea has persisted for at least a four year period as something useful in a prototype-based language, would a clone function be a good addition to the language itself?
A Clonable interface would be an OK addition. But cloning is tricky when it comes to mutable objects
a = { items : [1,2,3] };
b = clone( a ); b.items.reverse(); a.items[0]; // 1 or 3?
How deep should clone go?
It is the act of creating a object that inherits from/delegates to the provided object. Peter is suggesting sugar for one of the important mechanisms in a prototypal language. I believe the "copy" semantic is used in Self. "clone" is bit misleading (well, I think "copy" is too). With classes, we call it "subclassing". We could call it "subobject" :). Douglas calls it "begetObjet" (nice), I personally think it is very valuable construct and I like what it encourages, but on the otherhand it is so easy/compact to create (about 4 lines of code), and it doesn't seem to be the direction ES4 is headed, so it's omission seems reasonable.
YAHOO.mst.app.code = (function(){ // 1100+ lines...
I don't think this doesn't have anything to do with the topic.
Kris
On 10/21/07, Kris Zyp <kriszyp at xucia.com> wrote:
javascript.crockford.com/prototypal.html It is the act of creating a object that inherits from/delegates to the provided object. Peter is suggesting sugar for one of the important mechanisms in a prototypal language. I believe the "copy" semantic is used in Self. "clone" is bit misleading (well, I think "copy" is too). With classes, we call it "subclassing". We could call it "subobject" :). Douglas calls it "begetObjet" (nice), I personally think it is very valuable construct and I like what it encourages, but on the otherhand it is so easy/compact to create (about 4 lines of code), and it doesn't seem to be the direction ES4 is headed, so it's omission seems reasonable.
function beget(o) { function F() {} F.prototype = o; return new F(); }
var x = { items : [1,2,3] };
var y = beget(x); y.items.reverse(); // reverse my y items.
x.items[0]; // What is it?
The point I made earlier about mutable objects addresses this very issue.
It's attractive, but easily breakable.
YAHOO.mst.app.code = (function(){ // 1100+ lines...
I don't think this doesn't have anything to do with the topic.
It's little off-topic. It can cause problems in real-world programming was the point I was trying to make. Looking at Doug's side made me remember that code and the (long, excruciating) time I spent, often @ the office until 8 or 10 on a Friday. I'm getting off topic again...
Garrett
With the proviso that the program unit proposal has still to be fully specified and debugged, I believe the following should work:
Somewhere:
unit Beget { internal package Beget { Object.prototype.beget = function (o) { /* what you expect */ } Object.prototype.propertyIsEnumerable("beget", false); } }
In your code:
use unit Beget "Somewhere";
In a browser, "Somewhere" would typically be a URI.
I have clone objects like this: //---------------------------------------------------- function cloneObject( srcObj ) { if( srcObj == null ) { return srcObj; } //undefined or null
var newObject; switch( typeof(srcObj) ) { case "object": newObject = new srcObj.constructor(); for( var property in srcObj ) { //Do not clone inherited values if( srcObj.hasOwnProperty(property) || typeof( srcObj[property] ) === 'object' ) { newObject[property]= cloneObject( srcObj[property] ); } } break;
default:
newObject = srcObj;
break;
}
return newObject; }
----- Original Message ---
cloneObject( this ); // Error if this is window.
// enumeration is partially broken in IE, this loop will sometimes fail for( var property in srcObj )
On 10/21/07, Kris Zyp <kriszyp at xucia.com> wrote:
javascript.crockford.com/prototypal.html It is the act of creating a object that inherits from/delegates to the provided object. Peter is suggesting sugar for one of the important mechanisms in a prototypal language. I believe the "copy" semantic is used in Self. "clone" is bit misleading (well, I think "copy" is too). With classes, we call it "subclassing". We could call it "subobject" :). Douglas calls it "begetObjet" (nice),
"liveClone" appeals to me.
I personally think it is very valuable construct and I like what it encourages,
This is one of the thing's I'm trying to determine. Does it encourage something really new or is it just some sugar or does it really create a different mindset in the programmer and hence functionally different code. Every example I've looked at so far is just as easily coded in the standard JavaScript way with a constructor, its prototype property and the "new" keyword.
but on the otherhand it is so easy/compact to create (about 4 lines of code), and it doesn't seem to be the direction ES4 is headed, so it's omission seems reasonable.
It seems ES4's big features are to appease the complaints about JavaScript and make it easier for programmers coming from Java. These are both worthy goals. However there can still be goodies for the enlightened ;-)
Peter
Is there a plan for a "clone" function in ES4?
Object.prototype.clone = function() { function F() {} F.prototype = o; return new F(); };
The earliest reference I have found to this function is a post by Lasse Reichstein Nielsen in 2003 on comp.lang.javascript
groups.google.com/group/comp.lang.javascript/msg/5d06e72e55d5bf11
In the past year this function has been evangelized by Douglas Crockford.
javascript.crockford.com/prototypal.html
Given the idea has persisted for at least a four year period as something useful in a prototype-based language, would a clone function be a good addition to the language itself?
Peter
Hi, Is there a plan for a "clone" function in ES4? Object.prototype.clone = function() { function F() {} F.prototype = o; return new F(); }; The earliest reference I have found to this function is a post by Lasse Reichstein Nielsen in 2003 on comp.lang.javascript http://groups.google.com/group/comp.lang.javascript/msg/5d06e72e55d5bf11 In the past year this function has been evangelized by Douglas Crockford. http://javascript.crockford.com/prototypal.html Given the idea has persisted for at least a four year period as something useful in a prototype-based language, would a clone function be a good addition to the language itself? Peter