callback() uses factored out interfaceMember() methods _reduceParrameter & _parameterParser

[adam-singer]

In this patch I'm assuming we can't reach the situation where a single callback definition in the WebIDL file has multiple parameters. The specification does allow for an argument list. Reviewing some of the .idl files it looks like a few of them might use multiple parameters for callbacks.

audio.idl:

  callback GetInfoCallback = void(OutputDeviceInfo[] outputInfo,
                                  InputDeviceInfo[] inputInfo);

file_system.idl:

  callback EntriesCallback = void (
      [instanceOf=Entry] optional object entry,
      [instanceOf=FileEntry] optional object[] fileEntries);

---

This patch also does not handle the situations where the callback defined in the idl has attributes which specify its type using instanceOf. instanceOf is not part of the standard so we will need to handle it.

IDL

  callback GetTabMediaCallback =
      void ([instanceOf=LocalMediaStream] object stream);

  interface Functions {
    static void capture(CaptureOptions options,
                        GetTabMediaCallback callback);
  }

Will generate

  Future<dynamic> capture(CaptureOptions options) {
    ChromeCompleter completer = new ChromeCompleter.oneArg();
    _tabCapture.callMethod('capture', [options, completer.callback]);
    return completer.future;
  }

But should generate

  Future<LocalMediaStream> capture(CaptureOptions options) {
    ChromeCompleter completer = new ChromeCompleter.oneArg();
    _tabCapture.callMethod('capture', [options, completer.callback]);
    return completer.future;
  }

---

Do we want to register the callback type for later lookup? Example like registering AlarmCallback in a parsed callback such as:

["AlarmCallback", "=", "void", [[EMPTY, [["Alarm", EMPTY], EMPTY, "alarm"]], EMPTY, ...], ";"]

---

regen apis to see changes

[devoncarew]

Re: the multiple parameters for a callback - this is a situation that we should handle but currently punt on in both the json parser and the code gen. We just use 'dynamic' in these cases, but should move to something like generating a new class just for this specific callback / Future return.

And re: the instanceOf, when we do parse that, just putting its value into the refName field of IDLType should be enough for the generation framework to do the right thing.

Thanks much for this patch! Will pull it in a see what happens. (I'm doing some socket work in a chrome app, and am encountering ref count exceptions with package:js when using package:chrome. I want to see if I can move over to using the generated APIs now since dart:js won't have the ref count issues.)

[devoncarew]

It's working! Awesome!

Future<int> bind(int socketId, String address, int port)

[adam-singer]

Nice!