[chuck-users] Cloning

[Hans Aberg]

On 11 Dec 2009, at 20:17, Kassen wrote:

> I see more issues here. A object may contain other objects, which in  
> ChucK's case might be Shreds. These Shreds have a state and I don't  
> think it's clear what we would do with that. For one thing you  
> couldn't make a *exact* clone in that case as both the original's  
> Shred and the clone's would need to be shreduled and they can't be  
> shreduled at the same spot (though of course they may be a the same  
> logical time).
>
> This seems natural and even interesting, considering the many  
> thought experiments about clones that slowly deviate from the  
> original, but it's something that would have to be kept in mind.

Some objects cannot be cloned, and others can, like files, but the  
expected default behavior is handing over e reference. In addition,  
one may want to have a deep clone - not just cloning the top level  
object.

So one might have one operator, say !=> which some objects that can be  
cloned properly may have. The => selects a default behavior. So for a  
file, => would mean @=> and for a float, !=>. Applying != on a  
streamwhich cannot be copied would produce an error.

This would be for a top-level clone, which is what is used the most.  
For a deep clone, introduce yet another operator !!=>. It produces !=>  
on the subobjects that have it, but @=> otherwise. So if an object  
contains a float that can be copied and a stream that cannot, !!=> on  
the object will copy the float, but hand over a reference of the stream.

In addition, a label "const" might useful to prevent copying. If I write
   Interval m2;   m2.setr(256.0/243);   // Pythagorean minor second.
then it is clear that I do not want the value m2 altered by mistake.

   Hans