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
<heuermh@gmail.com> wrote:
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.
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
--
http://michaelclemow.comhttp://semiotech.org