[chuck-users] Intraspection - an example of what I'm attempting

mike clemow michaelclemow at gmail.com
Tue Nov 9 11:43:01 EST 2010

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,

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.


On Mon, Nov 8, 2010 at 2:50 PM, Michael Heuer <heuermh at 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.
> 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20101109/250bf8f5/attachment.html>

More information about the chuck-users mailing list