2009/10/1 Kassen
The current scheme -- using the (lexically) first function definition -- seems fraught with astonishment.
I don't think the situation is terrible;
I do. This is one of the things that really gets up my nose in ChucK.
it doesn't crash,
Oh. Good.
correct behaviour can be had
Are you familiar with the concept of Turing Equivalence? Once a language reaches a certain expressive power, it's not about whether or not you can get things to happen, it's about how much pain you ut the programmer through.
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.
And the above behavior essentially breaks the main utility of behavioral inheritance: that you can cause more-specific behaviors to occur in a more-general context. Really, this is just wrong.
mattering, yet it does. The other cases that I know of are just plain bugs.
Then perhaps so is this.
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.
So it's a bug that you know how to fix? david rush -- GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt