Oh heck, let's just cut to the chase and hack a Chuck
meta-object protocol...
(oops, sorry. that just slipped out. ;)
Honestly, I've run into this a lot in the past and I'm familiar with this
frustration. I even hacked my own version of chuck in which each object
responded to a .typeOf(); message that returned a string representation (I
know, it's ugly) of it's class name. I used this to make do smart casting,
which I admit is still a huge compromise. I still think that each class
name (reserved word) should be able to represent itself. Something to the
tune of:
if( myUgen.typeOf() == SinOsc ) { // seems reasonable, right?
myUgen $ SinOsc => SinOsc s;
}
But even then, short of wrapping all UGens in another class in order to gain
more control from these sorts of operations, we still have to do the cast
ourselves, which would make some sense if it was ever reasonable to cast a
SinOsc as anything other than a UGen, but that would be... frankly,
bizarre.
For this reason, I think that the Chuck language should take care of this
situation for us (at least where UGens are concerned--we can build). If we
are forced to cast because Chuck is strictly typed, so be it. But then we
should be able to ask any object what it really is an instance of. There
are good reasons why Chuck is strictly typed, however, IMHO, this is an
unnecessary restriction. Even Java can do this--and I rarely stick my neck
out for Java.
Anyway, I've been on this soapbox before, so I'll stop my drivel.
Mike
On Mon, Nov 8, 2010 at 2:50 PM, Michael Heuer
Kassen:
Andy;
I'm not sure that's true. I just tried this:
You are right. I doubted for a moment because of the array and how arrays tend to muck with the type system but this fails too; JCRev foo; .1 => ((foo $ UGen) $ Chorus).mix;
The "mix" method won't have a common location in the vtable. You might get lucky casting a JCRev to a PitShift since "mix" is the first method for both of them, but I certainly wouldn't count on that to always work.
Indeed! Turns out we just got lucky a lot of times. It does work for the STKInstruments and the convenience filters. I seem to remember you can also have it work for anything that has a .freq() but maybe there too we just got lucky so far. That's a bit disappointing; it was a nice trick while it lasted. I suppose it still is for those places where you can get away with it. I think I talked about this before, but I'd like any object to have a .type() that would return a array like this; ["Object", "UGen", "Filter, "LPF"]. The VM has all of that data, we just can't get to it.
There is some relevant code for the cast operator, chuck_type.cpp, line 2488 and related. It looks rather incomplete to me, and maybe this is the most telling
line 2530: // TODO: dynamic type checking
If anyone can hack together an instanceof operator from this, the effort would be greatly appreciated. :)
michael _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users