- From: Shiki Okasaka <shiki@google.com>
- Date: Wed, 17 Jun 2009 18:47:55 +0900
- 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