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
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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users