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

[mike clemow]

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