Expand on issues with existing techniques

[sorvell]

I think any of these composition / sharing systems need to rely on documentation so that it's clear what the feature does and how to use it. This seems to blunt some of the criticism, at least to some extent, and the question then becomes: is the technique hard to document and understand?

Given this, it would be helpful to address these points:

• Subclass factories (mixins)

  • Pollution of the inheritance chain: what is the actual problem here and how would documentation not address it?
  • Requires additional code to deduplicate mixins: can be handled with documentation and is also covered by the explicit mixin proposals.
  • Hinders debugging: don't folllow, can you provide an example?
  • Every mixin needs to call super.methodName?.() defensively: Why? Using super is a feature you should use or not based on your undersatnding of the feature.

• Delegation Pattern

  • (Major) No way to add API surface to the class: can combine with mixins to do this.
  • Because the glue code is manually authored: delegate and mixin can be provided together.
  • No good way to extend existing methods in the host class: possible when combined with mixin.
  • No way to check whether a given class implements a certain delegate or not: possible when combined with mixin.
  • No way to add a delegate to a class from the outside: what's the use case for this?