[chuck-users] assignment (BUG?)
signal.automatique at gmail.com
Sun May 31 17:59:50 EDT 2009
 For "immediate" data types (ints, float), => and @=> are identical: they
> move the data, not the pointer. This is why
> int foo;
> int bar;
> foo @=> bar; // assigns 0 to bar
> 1 => foo;
> doesn't modify bar -- bar will still have a value of zero.
> Any disagreements?
Yes, sorry but I have to disagree. I don't see why I shouldn't be allowed to
have primitives reference each other; I don't see any use in two operators
accomplishing the same thing and when we'd want another type of behaviour
we'd need to encapsulate the variable in a array.
Sadly the online language specification doesn't have a great deal to say on
this but the manual states; "similarly, reference assignment duplicates a
reference to an object and assigns the reference to a reference variable.
The object itself is not duplicated. All ChucK object assignments are
Sadly (for me) the ChucK parser disagrees with me and feels integers aren't
objects, to demonstrate;
int bar @=> foo; //this fails
True; the manual exclusively covers objects but it doesn't actually define
what should happen in this case at all. It's my opinion that either @=> and
=> should do something different when applied to primitives or the
assignment should at the very least cause a warning. I'm leaning towards the
first option as I can see uses for it. I might have a shred that
periodically sends "float foo" to the frequency of my instrument. I might
then later want to assign some other variable to foo so that this shred will
then send whatever that variable holds to this frequency.
The chuck operator "=>" is "masively overloaded" and that's a good thing
(hopefully) but it makes no sense to me to also overload "@=>" to also mean
"=>" under certain conditions. To address Hans's point, the chuck operator
can indeed be used on types that can be assigned as well; for example to
connect UGens or to chuck Events to now. These things aren't mutually
exclusive; Events and UGens can both be assigned and chucked to eachother.
Clearly there is no issue with dis-allowing certain operators on certain
objects, we can't use "%=>" on a Gain, for example. It's not clear to me why
@=> as applied to primitives is a exception here and is instead overloaded
to mean "=>". It's no huge issue but I would like to understand why it is
like it is.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users