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

Thu Feb 12 03:14:05 EST 2009

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 <gelfmuse at gmail.com>  
> 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  
>> <ravelite at gmail.com> 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 <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
>>>>
>>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> -- 
> http://michaelclemow.com
> http://semiotech.org
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users