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

Graham Coleman ravelite at gmail.com
Wed Feb 11 07:27:15 EST 2009


I submitted a patch to the dev-list ages ago for one of my hacks

It's probably not the best way to do this, as it introduces a new bytecode.



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

More information about the chuck-users mailing list