Rob;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">[2] For "immediate" data types (ints, float), => and @=> are identical: they move the data, not the pointer. This is why<br>
int foo;<br>
int bar;<br>
foo @=> bar; // assigns 0 to bar<br>
1 => foo; <br>
doesn't modify bar -- bar will still have a value of zero.<br>
<br>
Any disagreements?<br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" target="_blank"></a></blockquote><div><br>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.<br>
<br>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 reference assignments."<br>
</div></div><br>Sadly (for me) the ChucK parser disagrees with me and feels integers aren't objects, to demonstrate;<br><br>Object foo;<br>int bar @=> foo; //this fails<br><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>Yours,<br>Kas.<br>