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.