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

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 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 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>>>; <<>>;

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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

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