This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21295 - overload resolution: are DOMString and sequence<T> distinguishable now?
Summary: overload resolution: are DOMString and sequence<T> distinguishable now?
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
Whiteboard: [v1]
Depends on:
Reported: 2013-03-14 23:53 UTC by Travis Leithead [MSFT]
Modified: 2013-08-04 09:10 UTC (History)
5 users (show)

See Also:


Description Travis Leithead [MSFT] 2013-03-14 23:53:25 UTC
In the Screen Orientation spec:

the interface specifies an overload between a sequence<DOMString> and a DOMString:

  boolean lockOrientation (DOMString orientation);
  boolean lockOrientation (sequence<DOMString> orientations);

So, when an implementation gets a DOMString as a parameter, I wondered how I could tell whether I should apply the sequence<> conversion logic, or take the DOMString as-is? 

The sequence<T> conversion logic would seem to take a DOMString "Hi", and per section 4.2.24:

I'd fall through to the "Any kind of object except for a native Date object or a native RegExp object" rule.

DOMString's have a length (2 in this case), so I'd end up either taking the DOMString as is (one viable outcome) or converting the DOMString into ["H", "i"] per 4.2.24 (equally valid outcome). 

I think that means that these two types are not distinguishable anymore? Somehow I don't think that's the intent...
Comment 1 Boris Zbarsky 2013-03-15 01:13:40 UTC
DOMString and sequence are distinguishable, yes.

As for how you decide which overload is being called, that's described at

In this case, step 13 is reached with i == 0.  The substeps of step 13 are followed, you skip step 7 because V is not an object, and then step 8 treats it as a DOMString.

That's assuming what's passed in is a primitive string.  If a JS String object is passed in, it will in fact be treated as a sequence the way the spec is currently written, as far as I can tell.  That might be worth fixing....
Comment 2 Anne 2013-07-10 13:53:45 UTC
Note that "DOMString, DOMString..." or maybe just "DOMString..." would be preferable signature.
Comment 3 Cameron McCormack 2013-08-04 09:10:30 UTC
As Boris says, these are distinguishable now, and the rules in #dfn-overload-resolution-algorithm should work.