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

Shiki Okasaka:
> I see. So the expected ECMAScript behaviour is to try to invoke an
> operation that can be executed without applying ToString(),
> ToNumber(), etc., to [AllowAny] parameters firstly, and then look for
> an invokable operation taking [AllowAny] into account if no such
> method was found?

Sort of.  Primitive types are all lumped together, and a ToNumber(),
ToBoolean() or whatever will still be applied to the value passed in.

I just committed the change to the overload resolution algorithm, which
I forgot the other day:

  http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm

It’s clearer now from that algorithm (hopefully) that for a given
ECMAScript type/value, certain IDL types are considered appropriate:

  ECMAScript value     Appropriate IDL types
  -------------------  ---------------------

  Undefined, Boolean,  Primitive types, boxed primitive types, any
  Number

  String               DOMString, any

  null                 Object types, boxed valuetypes, DOMString, any

  Host object          Object, any interface type for an interface that
                       the host object implements (or one of its sub-
                       interfaces), any

  Native object        Object, any interface type for an interface
                       annotated with [Callback], any

For a given argument, if there is an overloaded operation that has an
appropriate type, all entries in the set of possible operation
invocations that have an inappropriate type will be removed.  However,
if there is no operation that has an appropriate type, but there is one
with an inappropriate type but which is annotated with [AllowAny], then
it will remain in the set.

When it comes to actually invoke the selected operation, the conversions
in #es-types that do ToObject() or ToUint32() or whatever will still be
performed as appropriate.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 19 June 2009 02:18:16 UTC