electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Articles  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links  |  Store
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
Live streaming at radio.electro-music.com

  host / artist show at your time
  EdisonRex Edison's Electronic Review
Please visit the chat
 Forum index » DIY Hardware and Software » ChucK programming language
Mixing subclassed objects in an array?
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [13 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
cbit



Joined: Dec 01, 2005
Posts: 35

PostPosted: Mon Nov 02, 2009 5:02 pm    Post subject: Mixing subclassed objects in an array? Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Mon Nov 02, 2009 7:24 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Send e-mail Visit poster's website
cbit



Joined: Dec 01, 2005
Posts: 35

PostPosted: Tue Nov 03, 2009 3:01 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Visit poster's website
Antimon



Joined: Jan 18, 2005
Posts: 3618
Location: Sweden
Audio files: 254
G2 patch files: 95

PostPosted: Tue Nov 03, 2009 4:37 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Visit poster's website
cbit



Joined: Dec 01, 2005
Posts: 35

PostPosted: Tue Nov 03, 2009 5:46 am    Post subject: Reply with quote  Mark this post and the followings unread

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:
new B() @=> A @ a;

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
View user's profile Send private message Visit poster's website
Antimon



Joined: Jan 18, 2005
Posts: 3618
Location: Sweden
Audio files: 254
G2 patch files: 95

PostPosted: Tue Nov 03, 2009 6:11 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Visit poster's website
cbit



Joined: Dec 01, 2005
Posts: 35

PostPosted: Tue Nov 03, 2009 6:51 am    Post subject: Reply with quote  Mark this post and the followings unread

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) Embarassed

Thanks for the patient explanations and refraining from replying with a richly deserved 're-RTFM' Smile

_________________
http://basementhum.blogspot.com
Back to top
View user's profile Send private message Visit poster's website
Antimon



Joined: Jan 18, 2005
Posts: 3618
Location: Sweden
Audio files: 254
G2 patch files: 95

PostPosted: Tue Nov 03, 2009 6:53 am    Post subject: Reply with quote  Mark this post and the followings unread

No problem. Explaining things gives the illusion that I actually know something. Smile

/Stefan

_________________
Antimon's Window
@soundcloud @Flattr home - you can't explain music
Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Tue Nov 03, 2009 10:30 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Send e-mail Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Tue Nov 03, 2009 10:39 pm    Post subject: Reply with quote  Mark this post and the followings unread

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 Smile

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Inventor
Stream Operator


Joined: Oct 13, 2007
Posts: 5978
Location: San Antonio, Tx, USA
Audio files: 258

PostPosted: Tue Nov 03, 2009 11:01 pm    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Send e-mail
cbit



Joined: Dec 01, 2005
Posts: 35

PostPosted: Wed Nov 04, 2009 2:34 am    Post subject: Reply with quote  Mark this post and the followings unread

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
View user's profile Send private message Visit poster's website
Antimon



Joined: Jan 18, 2005
Posts: 3618
Location: Sweden
Audio files: 254
G2 patch files: 95

PostPosted: Wed Nov 04, 2009 4:28 am    Post subject: Reply with quote  Mark this post and the followings unread

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. Smile This is definitely a bug in ChucK.

/Stefan

_________________
Antimon's Window
@soundcloud @Flattr home - you can't explain music
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [13 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » ChucK programming language
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
AmbiphonicDSP

Please support our site. If you click through and buy from
our affiliate partners, we earn a small commission.


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use