What does "Clone" do in JAVA?
Community Forums/General Help/What does "Clone" do in JAVA?
| ||
| I am reading through someone's source code and wondering what clone does. I am not exactly what this feature is in Java. As far as I can tell clone makes a copy of an object and adds it to the top of the stack of objects. I could be wrong. Here is the code I am looking at :-
public Object clone() throws CloneNotSupportedException
{
RecordInfo cloneinfo = (RecordInfo)super.clone();
cloneInfo.clearTime = clearTime.clone();
return cloneInfo;
}
What would maybe be the equivalent in Blitz? Ta :) |
| ||
| As the name implies, makes a new object: http://en.wikipedia.org/wiki/Clone_%28Java_method%29 The biggest reason for overloading it (rather than making it some kind of built-in operator) is because which stored values within the object actually need to be cloned themselves (as in this case) and which ones can be simply reference-copied will be up to the developer and isn't passed to the compiler (although... that would be really easy to do). If a class has some kind of "stack", it might also take care of things like that. Do what you want in it! Since BlitzMax's root object class doesn't provide a "clone" or "copy" method, there is no direct equivalent. In 99% of cases I can't see this being a problem (by the sound of it, the fact that clone belongs to Object and returns an Object may actually be a hindrance as often as it is helpful). Last edited 2012 |
| ||
| Hi Yasha, thanks the link and explanation, I was actually looking at that Wikipedia link earlier. One thing that struck me was the super.clone part. How is that different from a this.clone? As you say this sort of thing is probably more of a hindrance, the code above seems a bit like overkill to me for simply copying an object. |
| ||
| Well the thing to remember is that only Object.clone() actually does anything special, i.e. actually create a new object the same size and shape as the old one regardless of original class (magic builtin functionality); the overridden implementations are just regular methods. So the chain of calls to super.clone() are how each implementation of the method actually gets the newly cloned object, so that they can then update anything that needs to be changed, before returning it. Say the method above belongs to the third class (B) in a chain that goes Object -> A -> B, where its superclass A has some other field "x". B.clone() calls its superclass's method, A.clone(), which calls Object.clone() to work some magic and get the actual full-sized object. A.clone() does something useful with field x, because the standard principle of inheritance lets it work on the portion of the object that it understands, then returns the half-modified clone to B.clone() which knows that the "cleartime" field also needs a deep copy, and does the rest of the work (on the part of the object which B.clone() can see, which may not be the whole object if there are also classes C, D etc. that extend B). This is in contrast to something like a constructor, which has language-level support and therefore invokes the appropriate superclass constructors automatically before running itself. Basically this is one of those areas that Java is so famous for where you can spend all day writing more and more code, outlining incredibly complex class structures and invoking design patterns, while achieving absolutely nothing that actually does anything. Last edited 2012 |
   |