[chuck-users] parent and children classes (I meant polymorphism)

[mike clemow]

> ps; you'll be fighting the type system. Typically fighting the type system leads to bug-reports. If it's 4am and you're
> throwing the keyboard against the wall do considder that you may be right and ChucK might be wrong.

Man, that sounds familiar...  ;-)

I end up fighting the type system all the time, actually.  I ran into
a very similar situation in which I was trying to make a Collection
class.  Why can't I do this kind of thing?

class Collection {
	Object objects[0];
	0 => int count;
	
	fun void add( Object obj ) {
		objects << obj;
		count++;
	}
	
	// this you can't do, apparently...
	fun Object pop() {
		//objects.popBack() @=> Object s;
		//return s;
	}
}

Collection myCollection;

SinOsc s;
Gain g;
Event e;

myCollection.add( s );
myCollection.add( g );
myCollection.add( e );

<<< myCollection.count >>>;

// so far so good...

// this doesn't work...
//myCollection.pop() $ Event @=> Event f;

//-------

I really wish that there was at least an isInstanceOf() method (like
in Java, sadly), we could use to programatically determine the class
of an object at runtime.  It's my personal, humble opinion that, if
you're going to have a strict typing system, you should provide a way
to programatically determine the type of anything.

-Mike


On Wed, Jan 21, 2009 at 9:58 AM, Kassen <signal.automatique at gmail.com> wrote:
> Scott;
>>
>> Not sure.  It's another one of those things that I think if fairly obvious
>> if you're coming from a C++ / Java-like type system, so it just seemed
>> natural to me to try.
>
> Ah, I see.
>
> I think it was the Joker in the Tim Burton Batman film who shouted "Where
> does he get those toys?" so that's where. I felt a bit like that :¬).
>
> This needs to be documented. It's great that we have such features, it's
> great that people with C/C++/Java experience can feel at home like that.
> What's not so great is if stuff like this has no documentation because that
> way nobody will know about it which would be a shame. I looked it up and
> right now cast is only mentioned in the manual as a way to turn int's into
> float's. We've seen some more examples of how it can be used but I had no
> idea it was *that* general. This changes the whole "fight with the type
> system game".
>
> It is of course spectacularly un-scientific to use yourself as a test-case
> and maybe my "Sherpa" title is making me vain these days but I more or less
> feel that if *I* don't know about it then it must be under-documented ;¬).
> We can't blame anyone for this, it's entirely logical that the developers
> -who are clearly very experienced with this type of syntax- will feel some
> things are so natural that they overlook mentioning them. I'll add this to
> the "missing documentation" page on the wiki tonight.
>
> I did some quick testing just now to make sure I understand it all and there
> is a small issue with this in that we can now address member functions that
> aren' t there which leads to crashes.
>
> //This is fine (if pushing what's sensible to do in one line);
> new SinOsc @=> UGen foo => dac;
> 400 => (foo $ SinOsc).freq;
> second => now;
>
> //this is not fine
> UGen u;
> 200 => (u $ SinOsc).freq;
>
> Of course this is rather predictable but it also means losing the whole VM
> and IMHO anything that makes us lose the whole VM is a issue.
>
> So, a new trick learned and a new way of crashing unearthed, it's a good day
> for ChucKing!
>
> Thanks,
> Kas.
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>



-- 
http://michaelclemow.com
http://semiotech.org