| Author |
Message |
cbit
Joined: Dec 01, 2005
Posts: 35
|
 Posted: Mon Nov 02, 2009 5:02 pm Post subject:
Mixing subclassed objects in an array? |
  |
|
If I'm not overlooking something obvious (very possible) I'm sure this must have been asked before so apologies if the information is actually under my nose somewhere:
I ran into a snag where i expected to be able to have objects of class A as well as objects of class B (which extends A) in the same array. But the following code gives an error:
| Code: | class A{
}
class B extends A{
}
A a;
B b;
A as[];
b=>as[0]; |
[arraytest.txt]:line(11): cannot resolve operator '=>' on types 'B' and 'A'...
[arraytest.txt]:line(11): ...(note: use '@=>' for object reference assignment)
Is this an unreasonable expectation on my part? (or am i doing something weird/wrong?) and if not, how are you guys working around this kind of thing?
_________________
http://basementhum.blogspot.com |
|
|
Back to top
|
|
 |
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Mon Nov 02, 2009 7:24 pm Post subject:
|
|
|
First of all; the chuck operator ( => ) isn't overloaded to deal with types "A" and "B". what you would use here is assignment, for which we use "@=>".
We also need to "cast" b to be treated as a "A", for which the "$" (pronounced as "cast to type..") is used.
Your code would then look something like;
| Code: |
class A{
}
class B extends A{
}
A a;
B b;
A as[2]; //needs a length
b $ A=>as[0]; |
If you'd wander the landscape of ChucK-syntax with a GPS device then your screen would now be saying "here be dragons". We do know roughly, what sort of dragons and have a few ideas on their nature and how they can be pacified (they like "@" signs, for example), but they are here.
_________________
Kassen |
|
|
Back to top
|
|
|
cbit
Joined: Dec 01, 2005
Posts: 35
|
| Posted: Tue Nov 03, 2009 3:01 am Post subject:
|
|
|
Thanks Kassen, that makes sense. I do recall now having read both these pieces of information elsewhere, but somehow they were too far back in my head as I was writing this.
In light of what you just said, I'm not sure I understand what the chuck manual means when it says this about arrays:
| Quote: | | initializers must contain the same or similar types. the compiler will attempt to find the highest common base type of all the elements. if no such common element is found, an error is reported. |
Is this accurate? I was thinking that the highest common base type of an A object and a B object is A (if B extends A), yet I don't seem able to get these to coexist in an array (either at initialisation or by assignment) without using casting as you explained.
EDIT
Sorry, i must have been doing something else wrong, this code does work as the manual suggests it would!
| Code: | class A{
}
class B extends A{
}
A a;
B b;
[a, b] @=> A as2[]; |
_________________
http://basementhum.blogspot.com |
|
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005
Posts: 4145
Location: Sweden
Audio files: 371
G2 patch files: 100
|
| Posted: Tue Nov 03, 2009 4:37 am Post subject:
|
|
|
Yeah, you shouldn't need to cast B to A - ChucK can always deduce this by the way B is declared ("extends A"). It's different the other way around, however:
| Code: | new B() @=> A @ a;
(...)
a $ B @=> B |
needs a cast because ChucK can't assume that the a variable hasn't changed to contain an instance of some other class that extends A.
/Stefan
_________________
Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
|
Back to top
|
|
|
cbit
Joined: Dec 01, 2005
Posts: 35
|
| Posted: Tue Nov 03, 2009 5:46 am Post subject:
|
|
|
the @=> i'm starting to get a handle on, its the rough Object equivalent to the simple types assignment operator (=>) right?
But the use of @ alone is still mysterious for me. The manual shows it in an example but without an explanation of what's actually happening as far as i could see.
| Code: | // reference assignment
Object foo @=> Object @ bar; |
Any chance of an 'idiots guide' style explanation of what these lines are dong?
_________________
http://basementhum.blogspot.com |
|
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005
Posts: 4145
Location: Sweden
Audio files: 371
G2 patch files: 100
|
| Posted: Tue Nov 03, 2009 6:11 am Post subject:
|
|
|
I think as a kind of compromise between C and Java, these two kinds of declaring an object was implemented for ChucK:
| Code: | class A {
}
A a1;
<<< "a1=", a1 >>>;
A @ a2;
<<< "a2=", a2 >>>;
|
Run this and you'll see that a2 is null, i.e. it is not instantiated. You need to explicitly make an instance of A and assign it:
| Code: | new A @=> a2;
<<< "a2=", a2 >>>;
|
This way of doing stuff may be slightly recognisable to C (or other old programming languages) folks, who are used to dealing with instances as the norm, and needing to explicitly state if a variable is a pointer (in C you do this with an asterisk by the variable or type name).
The truth is that ChucK deals with objects pretty in a way that is pretty much identical to Java's, where all object variables are pointers. So both a1 and a2 are pointers to objects of type A, and they can even be assigned to each other (you can't do that in the C equivalent). The difference between variables that are declared with or without @ is whether they are initialized to a valid object or to null.
This is what I've deduced from reading what others say and doing my own experiments - like Kassen hints, it's not crystal clear.
/Stefan
_________________
Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
|
Back to top
|
|
|
cbit
Joined: Dec 01, 2005
Posts: 35
|
| Posted: Tue Nov 03, 2009 6:51 am Post subject:
|
|
|
Thanks
| Quote: | | The difference between variables that are declared with or without @ is whether they are initialized to a valid object or to null. |
Got it! And now I see that this too is covered in the manual (pg 81 82) 
Thanks for the patient explanations and refraining from replying with a richly deserved 're-RTFM' 
_________________
http://basementhum.blogspot.com |
|
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005
Posts: 4145
Location: Sweden
Audio files: 371
G2 patch files: 100
|
| Posted: Tue Nov 03, 2009 6:53 am Post subject:
|
|
|
No problem. Explaining things gives the illusion that I actually know something.
/Stefan
_________________
Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Tue Nov 03, 2009 10:30 pm Post subject:
|
|
|
| cbit wrote: |
| Quote: | | initializers must contain the same or similar types. the compiler will attempt to find the highest common base type of all the elements. if no such common element is found, an error is reported. |
Is this accurate? |
I tend to go with the docs. So I'd say that yes, it's accurate, but that's no use as the compiler is wrong...
| Quote: |
Sorry, i must have been doing something else wrong, this code does work as the manual suggests it would!
| Code: | class A{
}
class B extends A{
}
A a;
B b;
[a, b] @=> A as2[]; |
|
That's really quite interesting!
The type system currently has a few issues. In the past year and a half or so many of these came to light, partially as people started writing more advanced code and partially due to a start to a garbage collection system having been added which sometimes makes mistakes.
You are right; this is inconsistent.
_________________
Kassen |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Tue Nov 03, 2009 10:39 pm Post subject:
|
|
|
| cbit wrote: | the @=> i'm starting to get a handle on, its the rough Object equivalent to the simple types assignment operator (=>) right?
|
It's probably best to look at the "=>" operator in the way that the term "chuck operator" implies. It's massively overloaded and generally refers to "send (chuck) this there".
So; in the case of UGens we send the signal from one UGen to another. In the case of integers "a => b" refers to "take the value held by a and make b hold the same value". This is different from assignment. The function of the "=>" operator is more of a conceptual thing, that depends on the context where it's used. Most of the time this is intuitively clear but I have to admit that establishing permanently connections between UGens is quite different from copying a value or -say- passing a value to a member function.
"To chuck" we have to remember, refers to a bit of a crude way of throwing so in a way it fits
_________________
Kassen |
|
|
Back to top
|
|
|
Inventor
Stream Operator
Joined: Oct 13, 2007
Posts: 6221
Location: near Austin, Tx, USA
Audio files: 267
|
| Posted: Tue Nov 03, 2009 11:01 pm Post subject:
|
|
|
You guys never cease to amaze me. This stuff is over my head, but it's kind of interesting. Well, we all know our various subsets of knowledge and together we make it happen, eh?
Les
_________________
"Let's make noise for peace." - Kijjaz |
|
|
Back to top
|
|
|
cbit
Joined: Dec 01, 2005
Posts: 35
|
| Posted: Wed Nov 04, 2009 2:34 am Post subject:
|
|
|
| kassen wrote: | | You are right; this is inconsistent. |
Oh!, but I thought it was actually working the was the manual said it would: If B extends A. With an array of type A, no explicit casting required to initialise it with objects [a,b]. Is there another problem I'm overlooking?
Edit:
Ah: do you mean it's inconsistent that no explicit casting is required on initializing an array with mixed types, but that explicit casting is then required when subsequently assigning mixed objects to an array? That does seem a bit odd. If i understand correctly.
_________________
http://basementhum.blogspot.com
Last edited by cbit on Wed Nov 04, 2009 4:34 am; edited 2 times in total |
|
|
Back to top
|
|
|
Antimon
Joined: Jan 18, 2005
Posts: 4145
Location: Sweden
Audio files: 371
G2 patch files: 100
|
| Posted: Wed Nov 04, 2009 4:28 am Post subject:
|
|
|
I think Kassen is complaining about @=> versus =>, am I right?
I think the casting stuff is perfectly consistent with the way most other object oriented programming languages that I've encountered works. If B inherits from A, then you can always assume that B can do everything that A does, and you can assign objects of type B to variables of type A without needing to cast. You cannot, however, assume that A does everything that B does, so if you have a variable of type A can't copy its pointer directly to a variable of type B without checking the type (i.e. casting). If the A variable then points to some other class, you should get a fault.
However, I just did a little experiment with this, and weird stuff is going on...
| Code: | class A {
}
class B extends A {
fun void f() {
<<< "B: hello" >>>;
}
}
class C extends A {
fun void g() {
<<< "C: hello" >>>;
}
}
A aa[2];
A a1;
<<< "a1=", a1 >>>;
A @ a2;
<<< "a2=", a2 >>>;
new A @=> a2;
<<< "a2=", a2 >>>;
a1 @=> a2;
<<< "a2=", a2 >>>;
B b1;
b1 @=> aa[0];
b1.f();
C c;
c @=> aa[1];
aa[1] $ B @=> b1;
b1.f();
|
I now understand Kassen's comment about "Here be dragons", because this is what it prints out:
| Code: | $ bin/chuck test3.ck
a1= 0xd37878
a2= 0x0
a2= 0xd388e8
a2= 0xd37878
"B: hello" : (string)
"C: hello" : (string)
|
I expected this program to run along until the second last line (that assigns aa[1] to b1), and then generate a fault since you're trying to cast an instance of C to an instance of B. Instead, it happily continues to the next line, where it tries to run something that's called C.f() (since b1 now points to instance of C). C doesn't have any method called f(), so it runs g() instead (check what it prints)! How kind... I think I'd rather see it complain about my buggy code instead, though. This is definitely a bug in ChucK.
/Stefan
_________________
Antimon's Window
@soundcloud @Flattr home - you can't explain music |
|
|
Back to top
|
|
|
|
Forum index » DIY Hardware and Software » ChucK programming language
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
