Thanks, I've taken a copy and started adapting it. The old inheritance debate could drag on so I'll leave it that :) Loving expressive! - James
> On 24 Jan 2016, at 16:23, Marco Pivetta <[email protected]> wrote: > >> On 24 January 2016 at 12:41, James Abbott <[email protected]> wrote: >> Hi Marco, >> >> Thanks for your response. Good to know that the final handler is the right >> way to go. >> >> I'm not clear on why inheritance would be an invalid solution in this case >> though. Isn't it specifically intended for extending the functionality of a >> class in a scenario like this (where one class is a definite subtype of >> another and you want to reuse some of the parent classes' functionality)? > > That's a misconception of how `extends` is used: inheritance is a mean to > express different sub-concepts, not really a code-reuse mechanism. > >> Alternatively composition via an error handler interface in place of the >> handleErrors() method could be used. Both would provide more flexibility >> than locking down the whole class with private methods. > > The class can really just be copied into your namespace and adapted to your > needs: It is ~300LOC, mostly comments tho (much lower CLOC). > > It can be split into multiple collaborators (each of them being one of the > private methods, pretty much), but the benefits for the framework per-se are > minimal. I suggest simply moving it into your codebase as a first attempt, > and abstract only when there is solid ground for doing so. > > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ >
