Types of Composition #17

kitsonk opened this Issue Jan 8, 2016 · 2 comments


None yet

1 participant

kitsonk commented Jan 8, 2016

In talking about the prototype with @msssk in regards to the dojo/compose prototype, he is suggesting that that versions of composition that he is familiar with vary from the mechanisms we have implemented in the prototype. Specifically, instead of traits being mixed into the base prototype of the resulting class, traits are name spaced on to the class. The advantage is that it means that traits cannot have an dependency on the other and are enforced to be self contained.

For example, current api would be something like this:

const armFactory = compose({ grab() { /* method */ } });
const bodyFactory = compose({ breath() { /* method */ });
const humanFactory = compose(Body).mixin(Arms);

const human = humanFactory();

While what we discussed would be more like this:

const ArmTrait = compose.trait({ grab() { /* method */ } });
const BodyTrait = compose.trait({ breath() { /* method */ });
const humanFactory = compose({
    arm: ArmTrait,
    body: BodyTrait

const human = humanFactory();

In the second example, clearly arm cannot depend upon body and have to be designed in a way to where only human is aware of what traits it has. What do others think?

@kitsonk kitsonk added the discussion label Jan 8, 2016
kitsonk commented Jan 10, 2016

The more I was thinking about this, there are some problems I don't know if we can effectively solve with the latter. Mostly because certain traits would need to have an understanding of other traits and interface with them. For example, lets say we have a trait that has handles that need to be removed upon destruction. The trait needs to be able to call an own method, but it doesn't need to implement management of the handles or calling the handles upon destruction. That trait then might be componented into lots of other classes, who if they all implemented destruction. How would a final class work in that example?

@kitsonk kitsonk added this to the alpha.2 milestone Mar 11, 2016
@kitsonk kitsonk modified the milestone: 2016.04, alpha.2 Apr 8, 2016
kitsonk commented Apr 8, 2016

We have decided to continue to follow the current API.

@kitsonk kitsonk closed this Apr 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment