Establish standard mechanism for implementing static methods in DOM IDL

[vsmenon]

We have static methods popping up in upstream IDL. We need a standard way to map these. Currently, we do not expose these methods on any public interface or class by default. With operator call, we can do the following:

class _DOMURL_createObjectURL {
  const _DOMURL_createObjectURL();
  String operator call() => ...;
}

interface DOMURL {
  static final Function createObjectURL = const _DOMURL_createObjectURL();
  ...
}

main() {
  ...
  String url = DOMURL.createObjectURL(blob);
  ...
}

[larsbak]

Why does DOMURL need to be an interface?
Could it be a class instead?
//Lars

[rakudrama]

It can't be a class.

1. We use the same interface with different implementation classes for JS, Dartium.
2. The DOM libraries need to be able to distinguish real DOM objects from other classes that implement the interface - only the real DOM instances actually work when passed to DOM operations.

We also need a typedef for the Function type for each of the fake static function objects. Otherwise the editor will not be able to make good suggestions, e.g. the correct number and types of arguments.

[kasperl]

I didn't really think it through when I suggested this to Lars today, but my rough idea was to have an abstract class for DOMURL and use its implied interface like this:

  abstract class DOMURL {
    static String createObjectURL(blob) { ... }
    abstract foo();
  }

  class _DOMURL implements DOMURL {
    foo() { ... }
  }

That should solve 1 (as long as you don't need to use the default implementation of the interface) and maybe 2 still works? As I said, I didn't really think this through.

[vsmenon]

It's not clear to me how abstract classes would work in general.

The public interfaces make a deep tree. The private implementation classes (for either Dartium or Dart2JS) make a mirror tree. Then, pairwise, the implementation class implements its corresponding interface.

E.g., interfaces: CanvasElement extends Element extends Node extends EventTarget.

and classes: _CanvasElementImpl extends _ElementImpl extends ...

If we need to add a static method to CanvasElement, where do we put it?

[kasperl]

So you would have a tree of abstract "interface" classes like this:

    abstract class EventTarget ...
    abstract class Node extends EventTarget ...
    abstract class Element extends Node ...
    abstract class CanvasElement extends ...

and then you implement the implied interfaces for them in the parallel hierarchy:

   class _EventTargetImpl implements EventTarget ...
   class _NodeImpl extends _EventTargetImpl implements Node ...
   class _ElementImpl extends _NodeImpl implements Element ...
   class _CanvasElementImpl extends _ElementImpl implements CanvasElement ...

The static methods go into the abstract "interface" classes and you may need to add factory methods to them as well so if you try to construct a CanvasElement you really get a _CanvasElementImpl.

Still not quite sure if this works in general.

[gbracha]

As far as I can tell, this scheme should work just fine (unless there are further constraints that have not been mentioned). In particular, the objections raised in comment 2 do not seem to apply:

Every class has an implied interface, so an abstract class can be used as an interface.
You can distinguish the actual instances by their implementation class, even if they inherit from the abstract class(es). The abstract classes serve as the public types, and also provide the static methods.

Instantiating an abstract class via a factory constructor is perfectly legal, so make sure that the constructors are declared as factories and create the desired implementation classes.

At the moment, I don't see why this won't work. It's growing on me, as it nicely leverages implicit interfaces and factory constructors.

[vsmenon]

Clever! Renaming the bug title to reflect other options. :-)

So, two possibilities:

(1). Use operator call as sketched out in my first comment.

This is blocked on implementation:
Analyzer issue #1355.
VM issue #1604.
Dart2JS issue #2932.

It may require a level of overhead at runtime as well (i.e., singleton "function" objects).

(2). Use Kasper's abstract class scheme.

It looks like everything we need is implemented. It's a somewhat more significant rework, but it should be straightforward:

• public interfaces become public abstract classes
    - should the abstract Element class extend Node (the class) or implement Node (the implicit interface)? does it make a difference?
• methods are explicitly declared abstract
• "default" clauses are replaced by factory constructors

Any downsides to this approach?

---

Changed the title to: "Establish standard mechanism for implementing static methods in DOM IDL".

[DartBot]

This comment was originally written by antonm@google.com

---

The main problem is multiple inheritance which doesn't quite fit into Kasper's scheme. There is a workaround---just copy methods from other classes.

[vsmenon]

Note, you can modify Kasper's scheme to have the abstract classes just implement each other:

    abstract class EventTarget ...
    abstract class Node implements EventTarget ...
    abstract class Element implements Node ...
    abstract class CanvasElement implements ...

So, I think everything works out just as it does today. We'll of course still need the copy trick for the Impl classes.

[DartBot]

This comment was originally written by antonm@google.com

---

Yes, I know it, but the problem is with methods, the case:

IDL:

interface A { methodA(); }
interface B { methodB(); }
interface C extends A, B {}

Now we generate:

abstract class A implements B, C extends ?

Apparently whatever you put instead of ?, you'll have to copy another method for a second class.

[vsmenon]

Anton, why does A (actually, I think you meant C from IDL) need to extend anything?

IDL:

interface A { methodA(); }
interface B { methodB(); }
interface C extends A, B {}

Generate:

abstract class A {
  abstract methodA();
}

abstract class B {
  abstract methodB();
}

abstract class C implements A, B {
}

class _AImpl extends _DOMWrapperBase implements A {
  methodA() { ... }
}

class _BImpl extends _DOMWrapperBase implements B {
  methodB() { ... }
}

class _CImpl extends _AImpl implements C {
  // methodA() is inherited from _AImpl, methodB must be copied (as it is today).
  methodB() { ... }
}

It's not clear to me whether the abstract C needs to redeclare methodA or methodB. If I omit them, the editor doesn't give me a warning and my sample seems to run just fine.

[DartBot]

This comment was originally written by antonm@google.com

---

But now your abstract class doesn't implement promised interface which should trigger a warning, no?

[vsmenon]

But now your abstract class doesn't implement promised interface which should trigger a warning, no?

It currently doesn't trigger such a warning in the Dart editor & it (my simple test) works in Dartium and Dart2JS without warning or error. Surprisingly, the editor is even able to code complete methods on C that are not implemented in C (but are declared via implements and implemented in _CImpl).

Gilad / Kasper: should it be a warning if an abstract class does not implement the interfaces in its implements clause?

---

cc @gbracha.

[gbracha]

No. If a concrete class does not implement methods, that will cause
warnings. No issue with abstract classes.

[DartBot]

This comment was originally written by antonm@google.com

---

Gilad, thanks for explanations, sorry I wrongly assumed that abstract classes must implement methods.

[iposva-google]

Removed Area-DOM label.
Added Area-HTML label.

[vsmenon]

We're going with the abstract class route described here. Merging into 4525.

---

Added Duplicate label.
Marked as being merged into #4525.
Unmarked this as being blocked by #2931.