Robert;
Line [6] is up for grabs. I half expected it to call the version of process() with the <Specific obj> signature (since it called the Specific.announce() method at step [5]). On the other hand, obj was declared as a General class, so it doesn't surprise me that it called the version of process() with the <General obj> signature.
Yes, I agree with ChucK here; "obj" is defined as a "General" and correctly taken as a argument to the relevant function. It is *also* a Specific at this point, I believe, and could be cast to Specific at which point any member functions that Specific might have (that General would lack) should be available. In this case all Specifics are also Generals as well, by definition, and this one was defined as a General and thus treated as one. much like a cow, treated as a example of a herbivore, will still be a cow.
Line [7] is what bugs me: obj is cast to the Specific class, and the ChucK compiler _knows_ this at compile time. Yet it calls the process(General obj) function, NOT the process(Specific obj) function.
I found this quite baffling as well. Then I switched the order that the two versions of the overloaded function are defined in around and got; [chuck](VM): sporking incoming shred: 1 (unnamed1)... I am general: General:8ae4c10 processing general object: General:8ae4c10 I am specific: Specific:8add058 processing general object: Specific:8add058 processing specific object: Specific:8add058 I believe that to be the correct and expected behaviour. It seems that when multiple versions of a overloaded function could be used with a given object ChucK will take the top one of the options. I find that defensible, though it would probably be preferable if the default would be the least general case (so taking Sitar before STKInstrument, before UGen, before Object). Not a bug, I'd say, but a undocumented element of the syntax that might give unexpected results. It may need documentation and could perhaps use some polishing though. So; I learned something new, thanks! :-) Yours, Kas.