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.