Hide Construct.dependencyRoots

[eladb]

We wanted to ensure that the base Construct public API is clean (besides node) and leaves room for the API of the actual construct. Somehow dependencyRoots snuck in.

Is there a way to get rid of this? Why even use an override here? Can't we do something like:

construct.node.addDependencyRoot(x);

[rix0rrr]

It's not about Construct.dependencyRoots, it's about IDependable.dependencyRoots, and that interface is also implemented by non-Constructs.

I have a feeling this crops up a bunch, where we want to implement some polymorphic facility for some classes without necessarily dispatching through the object instance (because then the facility needs to show in the public interface, like here).

We can take the implementation out of the class. Something like traits:

// Marker interface purely so customers know which object to pass where (makes this
// distinctly less trait-like, but more usable). Otherwise, we type the function `foo`
// below as `foo(target: any)`.
interface IDependable {
}

// Declaration of trait
abstract class DependableTrait {
  public abstract dependencyRoots;
}

// Declaration of class unsullied by trait signature
// Does have a marker interface to help type checking.
class MyDependableThing implements IDependable {
  // ...
  // nothing about dependencyRoots here
  // ...
}

// Trait implemented separately from subject class
class SomeTraitImplementation extends DepenableTrait {
  constructor(subject: MyDependableThing) { }
  public dependencyRoots() {
    // Implementation using this.subject here
  }
}

DependableTrait.implement(MyDependableThing, SomeTraitImplementation);

// Usage site
function foo(target: IDependable) {
  const roots = DependableTrait.get(target).dependencyRoots;
}

We could do the same for bind() and other implementation-concern API surface.

[eladb]

I like the marker interface but I am wondering if perhaps the traits can be simply implemented inline. Doesn't seem like a separate class buys us too much, or maybe I am missing something.

interface IDependable { }
interface IDependableTrait {
  dependencyRoots: ...
}

class MyDependableThing implements IDependable {
  constructor() {
    Trait.implement<IDependableTrait>(this, {
        dependencyRoots: ...
    });
  }
}

// usage
Trait.get<IDependableTrait>(target).dependencyRoots...

Having said that, I am wondering if this pattern is actually that prevalent. I don't know if "bind" lends itself nicely to this, and I think that as we move to "integration classes", we'll see much less of this need.

Can we figure something out for dependencyRoots for now and see how it works?

[rix0rrr]

wondering if perhaps the traits can be simply implemented inline. Doesn't seem like a separate class buys us too much

In your code, we're mapping instances to instances. In my code, I was mapping classes to classes.

The latter will be more efficient if we're going to have a lot of instances of the same class.

---

    Trait.implement<IDependableTrait>(this, {

I was thinking this should still be accessible over jsii, so no generics.

---

Having said that, I am wondering if this pattern is actually that prevalent

It also occurs in the ELB library, where LBs and listeners and groups have a bind()-like protocol between them, AND the objects themselves expose a public API that customers are expected to call.

[rix0rrr]

Here's another rub: because of structural typing, marker interfaces don't mean anything in TypeScript. That is, I can do the following:

interface IDependable {
}

function doSomething(dep: IDependable) {
}


doSomething(new SomethingCompletelyUnrelated());

And TS won't complain. We can still do this, but the type marker will only be honored in non-TS languages.