Robert;
> I'll change your "probably be" to "": it WOULD be preferable to call the
> most specific version of an overloaded function. ChucK's class system has
> single, straight-line inheritance, so the "most specific" is always well
> defined.
You are probably ;-) right, I was hesitant to make a strong statement here as I wasn't sure this would hold true in all cases. There might be exceptions though now that I have thought about it for a while I have to admit I still haven't found any. I'm hesitant to make strong claims in fields like this because the situation might stretch to near infinite complexity and unforeseen possibilities may pop up.
> The current scheme -- using the (lexically) first function
> definition -- seems fraught with astonishment.
I don't think the situation is terrible; it doesn't crash, correct behaviour can be had and the results seem deterministic so far. It can also be improved without breaking old code in nearly all cases. My main issue is the lack of documentation. The manual just notes;
overloading
Overloading a function allows functions with the same name to be defined with different arguments.
The function must be written in separate instances to handle the input, and the return type must
agree.
...and gives some examples. I'd say it would also be useful to point out exactly what overloading is, because the above will make zero sense to first time programmers, why we would use it and note things like the above.
Generally the order in which functions and classes are defined in the code shouldn't matter, at least the specs don't make any mention of this mattering, yet it does. The other cases that I know of are just plain bugs. To me this seems like a case where the passes of the parser over the code don't exactly reflect what should be done and more should be moved to a preliminary pass that scans for definitions and files them appropriately for dealing with the rest of the code.
>
> Thanks for digging into this.
My pleasure; it was a good puzzle and the result taught us something new.
Yours,
Kas.