Re: [chuck-users] UGen based Pitch tracking demo (with BUG?)
Fellow ChucKists, A new year (at least on the Roman calendar). Us ChucKists should feel especially good about this one as the Roman calendar had a leap second this year; I don't think the rest of the universe is as strongly timed as we are. Anyway, a brand new year and brand new bugs, starting with one of mine. Consider this fragment;
//========member functions=====================
//sets time to average the input freq over. //reaction speed v.s. accuracy fun dur avgTime( dur length) { if (length < samp) { <<<"warning, duration too short, correcting">>>; ms => d.delay; } if (length > d.max()) { <<<"warning, duration too long, correcting">>>; d.max() => d.delay; } else length => d.delay;
.5 * (second / d.delay() ) => avg.gain;
return d.delay(); } //returns this time fun dur avgTime( dur length) { return d.delay(); }
Note that the second version shouldn't have the "dur length" parameter, it should be overloaded to get the averaging period, which might be useful at times, for example to make sure that this period isn't too short compared to the frequency we are getting. My fault; I was too hasty in my enthusiasm. Considder updating your files if you added this to a collection of useful code fragments. More generally; this means that we can apparently have overloaded functions that take the same argument(s) within the same scope. I don't think that's correct behaviour; this could lead to a lot of confusion and I can't think of a single instance where it would be beneficial. To make it more clear without any class being involved; //-------------- //this will parse and run; fun int foo (int bar) { return false; } //this one is just silly, in fact it won't even be called, the top one has priority fun int foo (int bar) { return true; } //------------- Now; "powertools can maim" and I don't mean to blame ChucK for a silly mistake that *I* made but do we really have a need to be able to have those two functions within the same scope? Can anybody think of a single instance where this could be useful at all? There are/were other instances where the overloading of functions wasn't propperly checked (particularly with regard to return types) which could/can lead to crashes. I feel it should be considdered to check for this as well when checks for that situation are added to the parser, even if this type of thing doesn't crash as such. Yours, Kas.
Kas says
Can anybody think of a single instance where this could be useful at all?
I don't think so. This sounds like a bug to me. If there are two declarations of the exact same function, for example your foo functions, then chuck should at least warn you that you've overdefined that function and tell you which version it will use. Actually, as I type I can see one area where I might do this. If you have a class that inherits from another class, you may want to redefine a function to do something different than its parent class. For example. public class Foo { 0 => int bar; fun int getbar ( ) { return bar; } } class AlwaysOne extends Foo { fun int getbar () { return 1; } } This is a somewhat silly example, but I could see it being done and I can't see why it should be illegal. I do think it would be nice for the VM to announce that it has been defined twice, and announce which version would be used (the last to be declared, I would imagine). Cheers, and Happy New Years! Rogan
Hey, Rogan!
I don't think so. This sounds like a bug to me. If there are two declarations of the exact same function, for example your foo functions, then chuck should at least warn you that you've overdefined that function and tell you which version it will use.
Yes, I agree there.
Actually, as I type I can see one area where I might do this. If you have a class that inherits from another class, you may want to redefine a function to do something different than its parent class. For example.
<snip> That's a good example of the way things currently work. I agree this is proper but here you aren't "over defining" terms but you are "re-defining" them, working from a general case (or scope) towards a specific one. This is quite different (I feel) from the example I posted where the two definitions were within the same scope. Re-defining functions while extending classes is kosher (and indeed essential), "over-defining" them is not, IMHO. I hope that helps illustrate my case an I wish you a very good new year to you as well. Yours, Kas.
participants (2)
-
Kassen
-
Rogan Carr