Re: [WebIDL] Make [AllowAny] the default?

On 9/12/11 11:32 AM, Brendan Eich wrote:
> Order is fragile under maintenance. It's brute force, you could do
> it, but more usable and less brittle would be something that accounts
> for type relations via inheritance, broadly construed. Didn't someone
> mention C3 already? (http://en.wikipedia.org/wiki/C3_linearization)

I don't quite follow.  C3 is for handling multiple inheritance, isn't 
it?  Or does the "broadly construed" above mean we should treat these 
within-a-single-interface overloading cases as a kind of inheritance 
hierarchy somehow, so that we can select between them with C3?

Currently in the spec there is a single case where order of operation 
declaration matters: if you have overloading on two types which are 
defined to be distinguishable but really you could have a value that 
matches both, e.g.

   interface A { };
   interface B { };
   interface C {
     void f(A x);
     void f(B x);
   };

It used to be that it would say "well it's up to the spec using Web IDL 
to disambiguate this case if you pass in an object that implements both 
A and B" but there was a request to make it able to be disambiguated 
just from the IDL.

What's being discussed in the other thread "overload resolution 
consistency" is how to ensure that if one day we have

   interface D {
     void f(DOMString x);
   };

which we call like d.f(123) and get the Number converted to a String, 
that we don't lose this when we later add an overload

   interface D {
     void f(DOMString x);
     void f(Node x);
   };

and my initial proposal there was to say "if you don't have exactly 
matching types for all arguments, just select the first overload and 
coerce the values appropriately".  (And Simon brings up a good point 
about that making certain APIs like some of the canvas methods suck in 
terms of getting the type slightly wrong, passing String instead of 
Number for example.)

If we could have an overload resolution behaviour that preserved 
d.f(123) selecting f(DOMString) then we can do away with [AllowAny].

Received on Friday, 9 December 2011 01:02:46 UTC