[chuck-users] class abuse

[Kassen]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20091001/0268707c/attachment.html>