Re: Why do we allow overloads on legacycallers?

Anne van Kesteren wrote:
> So talking with others in e.g. TC39 it seems the general feeling is
> that we should have less overloading of the type that happens in
> <canvas>. Maybe we could somehow split this algorithm in various ways
> and have the really complicated stuff be legacy opt-in in some manner?
> (Sorry for making this so open-ended, I haven't had time to
> investigate myself.)

Yeah, the overloading that happens in <canvas> is particularly egregious.

I'd be open to restricting certain complicated overloading to legacy 
APIs, if we can find a useful point to do that.

There aren't actually many instances of overloading in the platform that 
can't be rewritten with optional arguments and union types, although I 
know that some specification writers like to use overloading because 
it's easier to read than cramming things in to a single operation with 
union types.  We should probably start by looking at all of the current 
uses of overloading.

Received on Saturday, 3 August 2013 00:37:11 UTC