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

[mike clemow]

Kas,

> Hmmmm, but UGens are Objects too, and UGens do know their type, at least
> this shows us that their type is known.

You're right: they both inherit from Chuck_Object in the C++.  And,
this hack works just as well with SinOsc as it does with any handmade
class apparently.

> Would that cause terrible paradoxes that might destabilise the nature of the
> universe?

Well, that would take the "play" out of all this, wouldn't it?  ;-)

-Mike

On Wed, Feb 11, 2009 at 1: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
>
>



-- 
http://michaelclemow.com
http://semiotech.org