[chuck-users] determining the type of an Object in code
gelfmuse at gmail.com
Wed Feb 11 11:09:12 EST 2009
Sweeter still! This the key feature that your hack provides is this:
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...
On Wed, Feb 11, 2009 at 7:27 AM, Graham Coleman <ravelite at gmail.com> wrote:
> I submitted a patch to the dev-list ages ago for one of my hacks
> It's probably not the best way to do this, as it introduces a new bytecode.
> On Wed, Feb 11, 2009 at 7:17 AM, Kassen <signal.automatique at gmail.com> wrote:
>>> 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;
>> 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
>> 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
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
More information about the chuck-users