I'm not the expert, but I thought that the ChucK rules for assignment are: [1] For "reference" data types, (arrays and objects), @=> assigns the pointer, not the data. This is why Object foo; Object @bar; foo @=> bar; creates an "alias" of foo in bar. When you manipulate either one and you are operating on the same object. [2] 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? - r On 31 May 2009, at 13:42, Kassen wrote:
Fellow ChucKists,
Either we have a bug or I don't understand assignment (quite possibly both are the case, I won't rule that out). Consider this;
int foo, bar;
foo @=> bar;
//alternately, this gives the same result //bar @=> foo;
1 => foo; <<<"bar is", bar>>>; <<<"foo is", foo>>>;
I was expecting both to be 1 but here bar is 0 (Linux, miniAudicle modified to host 1.2.1.2). The following behaves as I expect it to;
int foo, bar;
1 => foo; foo @=> bar;
1 => foo; <<<"bar is", bar>>>; <<<"foo is", foo>>>;
Before I start bothering everyone with my ideas on assignment as it applies to UGens I'd like to be clear on what assignment does exactly and whether this is proper behaviour.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
--: Robert Poor e: robert.poor@nbt-ventures.com p: +1 617 818 5115 b: http://blog.nbt-ventures.com --: This message and the information it contains are the proprietary and confidential property of NBT Ventures and may be privileged. If you are not the intended recipient, please do not read, copy, disclose or distribute its contents to any party, and notify the sender immediately. --: