new API and old composition

[ghost]

Perhaps I'm missing something obvious here, but by changing the api to "possum returns something you interact with" from a "possum is the final step" I've had to rethink how composition works:

old

var spec = {
  // possum object with states, handlers, etc.
}

return someDecorator(spec)

// some-decorator.js
function someDecorator(possumSpec) {
  return possum(possumSpec)
    .compose(decoratedBehavior)
    .compose(mixinBehaviors)
}

This makes it rather easy to create a highly-composed stamp that sits on top of the base possum implementation.

new

var model = someDecorator()
  .config({ ... })
  .states({ ... })

return model

// some-decorator.js
function someDecorator() {
  return possum()
    .compose(decoratedBehavior)
    .compose(mixinBehaviors)
    .compose(ohNoIBrokeMyOtherComposition)
}

This gives the implementation override possibility over the decoration because of the order of invocation on .compose() . It's different, and probably for the better, but still: I DONT LIKE CHANGE!

I suppose I could monkey patch the old functionality, but I don't like monkeys:

function someDecorator() {
  var model = possum()
  var builder = model.build
  model.build = function() {
    model
      .compose(decoratedBehavior)
      .compose(yayImSafeNoOneRodeOverMe)
    return builder()
  }
}

Thoughts?

[mnichols]

I don't understand your second sample since it isnt valid. But...
possum() returns a builder. If you use compose then it will delegate to the underlying api model and compose those behaviors in. When you call build it will have your compositions in there.
If you want access to the underlying apimodel without calling build you can call stamp() on the builder.
If you are managing state separately you will need to call target on the resulting stamp, but you have full access to compose how you like using that method.

[mnichols]

Ok I think I follow you now...you are asking to extend all possums using a compose call on the builder factory.
I'll see what I can do