[chuck-users] determining the type of an Object in code

mike clemow gelfmuse at gmail.com
Wed Feb 11 11:44:16 EST 2009


I'm officially in over my head.  ;-)  Could the same thing be done as
a method of Object so that

SinOsc s;
s.instanceOf(SinOsc);  // returns 1 and
s.instanceOf(UGen);    // also returns 1?

Are you on github?


On Wed, Feb 11, 2009 at 11:09 AM, mike clemow <gelfmuse at gmail.com> wrote:
> Hi Graham,
> Sweeter still!  This the key feature that your hack provides is this:
> SinOsc s;
> s instanceOf SinOsc;  // true
> s instanceOf UGen;    // also true
> My hack only knows the type it was instantiated as.  The only issue I
> see with this is that, unless it also works on primitives, I would say
> that it ought to be a method of Object rather than a keyword/operator.
> Also, now that I'm typing this out, I'm favoring the keystroke-light
> isA() method...  hrm...
> -Mike
> On Wed, Feb 11, 2009 at 7:27 AM, Graham Coleman <ravelite at gmail.com> wrote:
>> Greetings.
>> I submitted a patch to the dev-list ages ago for one of my hacks
>> https://lists.cs.princeton.edu/pipermail/chuck-dev/2006-March/000135.html
>> It's probably not the best way to do this, as it introduces a new bytecode.
>> anyway
>> Graham
>> On Wed, Feb 11, 2009 at 7:17 AM, Kassen <signal.automatique at gmail.com> wrote:
>>> Mike;
>>>> Yes, like instanceOf() in other languages.
>>> Exactly. Maybe we should stick to conventions where they exist, even if
>>> .isA() is good for lazy typists.
>>>> Taking a class per se as an argument would necessitate looking that
>>>> token up in some list of classes available at runtime, no?
>>> Well, yes, I suppose, but that gets done anyway as ChucK has to make sure
>>> all objects we define are of a known type so ChucK already has to go over
>>> all previously defined types as well as the ones in the current file anyway.
>>> Clearly such a list exists somewhere in the system already (that need not
>>> mean it'll be easy to find for you or me, of course....).
>>>>  Also, it
>>>> seems that these things would have to be defined separately for UGen
>>>> and Object--as far as I can tell.  My C++ skills are next-to-absent,
>>>> to be honest.
>>> Hmmmm, but UGens are Objects too, and UGens do know their type, at least
>>> this shows us that their type is known.
>>> Gain shoe;
>>> <<<shoe>>>;
>>> <<<shoe.toString()>>>;
>>> I'm not sure I see the difference with other objects though there may be a
>>> big one in the C++ code?
>>>> In the meantime, taking a string representation of a class, like
>>>> "Object", for an argument would be much easier to implement (for me,
>>>> anyway).  We could do this just to prototype the feature, see if it's
>>>> useful, etc.
>>>> myObject.isA( "Object" )
>>>> Could return true or false.  This I think we could have up and running
>>>> quickly to try it out.  Perhaps then someone smarter than me would be
>>>> interested in looking into making it so that it could be done without
>>>> the quotes (i.e. as a class and not a string), which, I assume, would
>>>> be safer.
>>> Sure! Still, there are cases like STKInstrument where it would be very
>>> useful to know what type a certain object inherits from. In certain cases
>>> that might be even more interesting than the type of the object itself.
>>> Anyway, I like this plan. It's based on stuff we already have and it will
>>> make things like the type casting we talked about a short while ago much
>>> safer and more practical. Actually I think that we should make info that's
>>> available in the system already available within the language as much as
>>> possible.
>>> It will also be useful to be able to get the type of a object, like you
>>> sugest above, in adition to my idea because my proposal doesn't allow for
>>> comparing whether two objects are of the same type. I could imagine that
>>> making sure two objects are of the same type could come handy at times.
>>> Would it be possible to have a type "type"? It seems that that is something
>>> we are heading towards here if we'd like to avoid strings in this situation.
>>> Would that cause terrible paradoxes that might destabilise the nature of the
>>> universe?
>>> Yours,
>>> Kas.
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>> _______________________________________________
>> 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


More information about the chuck-users mailing list