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