IDL: Support optional argument default value syntax

Source/core/html/HTMLSelectElement.idl

 /*
  * Copyright (C) 2006, 2010 Apple Inc. All rights reserved.
  * Copyright (C) 2006 Samuel Weinig <sam.weinig@gmail.com>
  * Copyright (C) 2013 Samsung Electronics. All rights reserved.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
  * License as published by the Free Software Foundation; either
  * version 2 of the License, or (at your option) any later version.
  *
@@ skipping 20 matching lines @@
     attribute long size;
 
     readonly attribute DOMString type;
 
     readonly attribute HTMLOptionsCollection options;
     [RaisesException=Setter] attribute unsigned long length;
 
     getter Element item(unsigned long index);
     Element namedItem([Default=Undefined] optional DOMString name);
     // FIXME: should be union type http://crbug.com/240176
-    [RaisesException, TypeChecking=Interface] void add(HTMLElement element, [Default=Null] optional HTMLElement? before);
+    [RaisesException, TypeChecking=Interface] void add(HTMLElement element, optional HTMLElement? before = null);

[haraken, 2014/06/13 13:46:53]

Help me understand: How is this different from:

  [RaisesException, TypeChecking=Interface] void add(HTMLElement element,
optional HTMLElement? before);

?

[Jens Widell, 2014/06/13 14:14:52]

An optional argument without a default value causes the C++ implementation to be
called with fewer parameters, thus depending on overloads or default values on
the C++ side.

When there is a default value, that short-cutting is disabled, and we go ahead
with the value conversion, which I think mostly leads to coercing the undefined
into the argument's type.

[haraken, 2014/06/13 14:32:53]

Ah, got it, thanks! Is there any reason we support overloading in both C++ side
and binding side? It seems confusing that we have two ways of resolving method
overloading.

[Jens Widell, 2014/06/13 14:49:46]

I don't think there's a strong reason, and I think it would be nice if we could
drop the C++ side overloading (and possibility that C++ argument defaults affect
behavior) and instead let the IDL define everything.

The problem is, I guess, cases where we want to support "missing" as a separate
value for arguments (and null pointer, null string, et c. doesn't suffice.) And
Web IDL also notes that a trailing optional-without-default argument is
equivalent to having two overloads, one with and one without the argument, which
I guess matches how we currently call a different C++ "overload".

See also discussion in http://crbug.com/335871.

[haraken, 2014/06/13 14:59:03]

Understood.

I think we need a better rule for this. It's confusing to have multiple ways to
do one thing. For example: "we use IDL's overloading as much as possible except
for cases where we can't".

[Nils Barth (inactive), 2014/06/16 09:18:17]

Agreed; here're my thoughts:
* We should match IDL, which means using default values in IDL if present
(this means not needing to have them in C++, just making these required
arguments).
* C++ overloading is fine if there's no default value specified, and needed
anyway for overloads.

This gives a simple rule; I've updated the docs:
http://www.chromium.org/developers/web-idl-interfaces#TOC-Names

* Web IDL overloading and IDL optional arguments without default values map
directly to C++ overloading.
** Optional arguments without default values correspond to an overload either
including or excluding the argument.
* IDL optional arguments with default values map to C++ calls with these values
filled in, and thus do not require C++ overloading.
C++ default values SHOULD NOT be used.

[haraken, 2014/06/16 09:35:40]

Sounds reasonable to me.

     [ImplementedAs=addBeforeOptionAtIndex, RaisesException, TypeChecking=Interface] void add(HTMLElement element, long before);
     [RaisesException] void remove(); // ChildNode overload
     void remove(long index);
     [RaisesException, TypeChecking=Interface|Nullable] setter HTMLOptionElement (unsigned long index, HTMLOptionElement? value);
 
     readonly attribute HTMLCollection selectedOptions;
              attribute long selectedIndex;
              attribute DOMString value;
 
     readonly attribute boolean willValidate;
     readonly attribute ValidityState validity;
     readonly attribute DOMString validationMessage;
     boolean checkValidity();
     void setCustomValidity([TreatNullAs=NullString, TreatUndefinedAs=NullString] DOMString error);
 
     readonly attribute NodeList labels;
 };