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

I think both a member function and a keyword are good to have. The keyword way is much safer (the type can be verified at compile-time, and it doesn't need to throw an exception if the instance being tested is null). The member function way can be allowed to accept arbitrary, potentially non-existent type names, which comes in handy every now and then (suppose that you know a type will exist in the future, but its .ck file hasn't been added yet). You could also use a .isA() member function to implement hack-y generic container classes purely in ChucK code, which would be really cool to have. To the member-fun method's detriment, extending ChucK to allow compile- time type-checking of the type specified to .isA() seems pretty invasive, and without that it can be prone to simple but potentially elusive errors like .isA("Sinosc"). Similarly, modifying ChucK to accept raw, unquoted typenames as function arguments is no small task. Perhaps the solution here is adding a Object.typeName static method/ static variable, which returns a string, allowing code like s.isA(SinOsc.typeName) to work. That doesn't win any awards for terseness, but it seems like a good way to type-check this at compile- time without adding a new keyword. spencer On Feb 11, 2009, at 8:44 AM, mike clemow wrote:

Graham,

I'm officially in over my head. ;-) Could the same thing be done as a method of Object so that

SinOsc s; s.instanceOf(SinOsc); // returns 1 and s.instanceOf(UGen); // also returns 1?

Are you on github?

-Mike

On Wed, Feb 11, 2009 at 11:09 AM, mike clemow wrote:

...

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

-- http://michaelclemow.com http://semiotech.org _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users