Bugzilla

> 1. [You've been working on reducing boilerplate with the macros](https://bugzilla.mozilla.org/show_bug.cgi?id=1756510): Do you see this as alternative approach and we'd skip the macro patches then? 

Yup, with merged classes I don't think the macros are needed.

> 2. You link to Bug 1746077; I agree we'd have a cleaner situation this way. However, this also makes me wonder: we get into situations like `var source = { pull(controller) { ... } }`, where the Pull callback is IDL provided, but the start and cancel callbacks would be the default implementation. How does that end up looking in this world where we have a single object?

Maybe the IDL helper class can include the default implementation in that case?

```
// pseudocode...
class IDLUnderlyingSourceCallbacks {
  pull() {
    if (mPullCallback) {
      mPullCallback->Call();
      return;
    }
    DefaultImpl();
  }
}
```

> 1. [You've been working on reducing boilerplate with the macros](https://bugzilla.mozilla.org/show_bug.cgi?id=1756510): Do you see this as alternative approach and we'd skip the macro patches then? 

Yup, with merged classes I don't think the macros are needed.

> 2. You link to Bug 1746077; I agree we'd have a cleaner situation this way. However, this also makes me wonder: we get into situations like `var source = { pull(controller) { ... } }`, where the Pull callback is IDL provided, but the start and cancel callbacks would be the default implementation. How does that end up looking in this world where we have a single object?

Maybe the IDL helper class can include the default implementation in that case?

```
// pseudocode...
class IDLUnderlyingSourceCallbacks {
  pull() {
    if (mPullCallback) {
      mPullCallback->Call();
      return;
    }
    DefaultImpl();
  }
}
```

Edit: And if any native class ever need the default algorithms, then we can expose them as static functions.