Re: [selectors-api] Selectors API comments: section 2

Hi Lachy (and a question for Anne and Ian at the end).

Boris Zbarski:
>>> * I don't see any indication of what the language bindings for this  
>>> IDL should look like in languages which do not support function  
>>> overloading based on number of arguments and do not allow functions  
>>> with variable numbers of arguments.  If it has been decided that no  
>>> one is ever going to implement bindings for this specification in 
>>> such a language , it might be good to explicitly say so in the  
>>> specification so that it's clear that the problem has been  
>>> considered.  Another possible solution is to take the approach taken  
>>> in other existing DOM specifications and tack "NS" onto the end of 
>>> the name of a namespace-aware version of a method that is also 
>>> available in a non-namespace-aware version.  If the intent is to 
>>> indicate that the bindings in some languages may allow omitting the 
>>> second argument, I think that should be done via some mechanism that 
>>> doesn't look like normative IDL.

Lachlan Hunt:
> I would prefer to address this issue in the IDL, but I'm not yet sure  
> how to fix it.  The intention is for the methods to be overloaded, and  
> for implementations that don't support method overloading, then the  
> author will need to pass null as the NSResolver.
>
> Cameron, is there or will there be some way to deal with this issue in  
> WebIDL?

Two possibilities off the top of my head.  First is to handle optional
arguments differently from overloading, and then state that bindings for
languages that don’t allow overloading should just include the operation
with no arguments omitted.  For example:

  Element querySelector
    ([Null=Empty, Undefined=Empty] in DOMString selectors,
     [Optional] in NSResolver nsresolver);

[Optional] would mean that that argument, and all following it, could be
omittied.  That would allow you to do things like this:

  void f([Optional] in any a, in any b, [Optional] in any c);

which means you could call f() in three different ways:

  f()
  f(1, 2)
  f(1, 2, 3)

A second possibility is either [OmitIfNoOverloading] on the operation to
leave out, or [IncludeIfNoOverloading] on the operation to leave in, if
overloading is not supported in the language.  So that would be either:

  Element querySelector
    ([Null=Empty, Undefined=Empty] in DOMString selectors);

  [IncludeIfNoOverloading]
  Element querySelector
    ([Null=Empty, Undefined=Empty] in DOMString selectors,
     in NSResolver nsresolver);

or:

  [OmitIfNoOverloading]
  Element querySelector
    ([Null=Empty, Undefined=Empty] in DOMString selectors);

  Element querySelector
    ([Null=Empty, Undefined=Empty] in DOMString selectors,
     in NSResolver nsresolver);

Those names aren’t so nice though; suggestions welcome.


I think of those two, I would prefer the [Optional] one.  Optional
arguments seems to be what overloading is used for in the majority of
cases in specs being written at the moment.

Anne and Ian (since your specs use overloading for optional arguments):
any opinion?

Thanks,

Cameron

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

Received on Wednesday, 9 July 2008 23:26:54 UTC