W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

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

From: Shiki Okasaka <shiki@google.com>
Date: Wed, 17 Jun 2009 18:47:55 +0900
Message-ID: <2fdcc83a0906170247s6d3e9084gcb546ca5b310c97b@mail.gmail.com>
To: Shiki Okasaka <shiki@google.com>, public-webapps@w3.org
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?

 - Shiki

On Wed, Jun 17, 2009 at 6:15 PM, Cameron McCormack<cam@mcc.id.au> wrote:
> Shiki Okasaka:
>> The [AllowAny] extended attribute looks nice, and it will provide a
>> clearer ECMAScript runtime semantics. One thing still not very clear
>> to me is that a DOMString with [AllowAny] and a primitive type should
>> be distinguishable as in the example or not;
> I am thinking that [AllowAny] is an ECMAScript-specific extended
> attribute that just influences the overload resolution algorithm.  As
> such, it wouldn’t affect the definition of “distinguishable”.  So:
>  void f(in DOMString x);
>  void f([AllowAny] in long x);
> would remain distinguishable, unlike:
>  void f(in DOMString x);
>  void f(in any x);
>> maybe should we treat a parameter with [AllowAny] like an 'any' type
>> in an effective overload set for simplicity?
> It is effectively treated as ‘any’ in the overload resolution
> algorithm, since if the there is a true value in the list of booleans
> that is the third element of the triples in the effective overload set,
> any removals of entries from the set are skipped when looking at that
> argument position.
> --
> Cameron McCormack ≝ http://mcc.id.au/
Received on Wednesday, 17 June 2009 09:48:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC