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

[Kassen]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20090211/895aeda3/attachment-0001.html>