Re: [WebIDL] On overloaded operations in an effective overload set

Hi Cameron,

Thank you very much for the response. It's very nice for us to get
your perspective.

> Do you have an opinion on how disambiguation should be performed for an
> ECMAScript value passed in to such an overloaded operation?

I've chatted with several engineers and researchers about this. If
this interface A becomes an effective overload set in Web IDL, we need
a clear set of rules to resolve ECMAScript function calls like below
into either f2 or f3:

   a.f(123, "hello", "there", "3.14");
   a.f("not a number", "hello", "2.72", 3.14);
   a.f("123", 1234, "3.14", "2.72");

And it seems defining those rules would be not very easy. An
alternative proposed solution for this is to unify 'f2' and 'f3' by
using 'any':

  /* f2-3 */ void f([Optional] in any a, in DOMString b, [Variadic] in any c);

in which case we can defer disambiguation to the function
documentation and implementation, rather than something visible in the
types. Given that this sort of thing is very common in ECMAScript
libraries, and now we can use [Callback], [ImplementedOn], [Optional],
and [Variadic] extended attributes, it might be better to avoid
operator overloading by using the same identifier as much as possible.

I may be missing some nuance here, but the current draft
specification, which does not distinguish primitive types for
overloaded operation resolution, seems reasonable for supporting
ECMAScript efficiently at the moment.

Best,

--
Shiki Okasaka
Google


On Mon, Mar 2, 2009 at 8:45 AM, Cameron McCormack <cam@mcc.id.au> wrote:
> Hi Shiki.
>
> Shiki Okasaka:
>> I have a question about the overloaded operations in an effective
>> overload set in Web IDL.  In the example of 'Interface A' in 3.3.3.
>> Operation, the Draft 19 December 2008 says,
>>
>>     "There are thus no overloaded operation resolution ambiguities for
>> the interface",
>>
>> but the following three pairs seem to be not distinguishable to me,
>>
>>  * <f2, (DOMString, DOMString)> and <f3, (long, DOMString)>
>>  * <f2, (DOMString, DOMString, float)> and <f3, (long, DOMString, DOMString)>
>>  * <f2, (DOMString, DOMString, float, float)> and <f3, (long,
>> DOMString, DOMString, float)>
>>
>> based on the definition of 'distinguishable':
>>
>>     "Two types, t and u, are distinguishable if both are objects
>> implementing an interface (where two different interfaces are
>> identified) or if one is an object implementing an interface and the
>> other is a primitive type."
>>
>> Since 'DOMString', 'long', and 'float' are primitive types, there is
>> no index i such that the types at index i are distinguishable in the
>> above pairs.
>
> Yes, you are correct.  I think it would be helpful to allow DOMString
> and the other primitive types to be distinguishable, as the example
> would need.
>
> I’ve added a note to the editor’s draft to fix this up at some point.
>
> Do you have an opinion on how disambiguation should be performed for an
> ECMAScript value passed in to such an overloaded operation?
>
>> We are currently developing a Web IDL based RPC system for Native
>> Client (*) to facilitate defining interfaces between JavaScript and
>> Native Client based safe x86 modules, and a little clarification about
>> this section will help us with our Web IDL compiler development.
>
> Interesting to see a use of Web IDL other than in a W3C specification!
>
>> Also I found two typos in the draft:
>>
>> 3.8.13. [Variadic]
>> interface IntegerSet {
>>  readonly unsigned long cardinality; # 'attribute' is missing after 'readonly'
>>
>>  void union([Variadic] in long ints);
>>  void intersection([Variadic] in long ints);
>> };
>>
>> 4.2.5. [Replaceable]
>> interface Counter {
>>  [Replaceable] readonly attribute unsigned value;  # 'long' or 'short'
>> is missing after 'unsigned'
>>  void increment();
>> };
>
> Fixed, thanks.
>
> Cameron
>
> --
> Cameron McCormack ≝ http://mcc.id.au/
>
>

Received on Tuesday, 3 March 2009 05:22:04 UTC