Start a whitelist of methods those optionals should be treated as named formals in dart:html.

lib/html/scripts/generator.py

Index: lib/html/scripts/generator.py
diff --git a/lib/html/scripts/generator.py b/lib/html/scripts/generator.py
index c8ab91a4c35ffc3b4db187da30cf6a3d16ef29ed..1969f0bd3093b6d6ebbbc0783ae36e10a1f1ce3a 100644
--- a/lib/html/scripts/generator.py
+++ b/lib/html/scripts/generator.py
@@ -33,6 +33,11 @@ _pure_interfaces = set([
 def IsPureInterface(interface_name):
   return interface_name in _pure_interfaces
 
+

[Emily Fortuna, 2012/10/19 19:48:34]

nit: probably don't need two lines of whitespace here.

+_methods_with_named_formals = set([
+  'DirectoryEntry.getDirectory',
+  ])

[vsm, 2012/10/19 19:53:28]

One thing that worries me about named params is that we get the names from IDL
and they're practically comments there - no semantic value in JS.  They might
change arbitrarily.

Perhaps we can handle that by explicitly listing the optional params here with a
map from IDL parameter name to Dart name.  If the IDL name changes, fail and
force us to fix us here.  This would be a way to keep Dart names stable.

What do you guys think?

[Anton Muhin, 2012/10/23 13:59:53]

That's true, but my feeling is the chance of parameter name change is roughly
the same (or even less) as of method/interface.

Would you mind if we live for some time with names from IDLs and if we find them
not stable enough, resort to separate database for names?

On 2012/10/19 19:53:28, vsm wrote:

+
 #
 # Renames for attributes that have names that are not legal Dart names.
 #
@@ -237,7 +242,8 @@ def AnalyzeOperation(interface, operations):
   info.js_name = info.declared_name
   info.type_name = operations[0].type.id   # TODO: widen.
   info.param_infos = _BuildArguments([op.arguments for op in split_operations], interface)
-  info.requires_named_arguments = False
+  full_name = '%s.%s' % (interface.id, info.declared_name)
+  info.requires_named_arguments = full_name in _methods_with_named_formals
   return info