Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Though that wasn't the main point of the post, which was that if you just go about converting base classes to roles where you have recurrence of god objects, you will get god objects implemented with roles ;-)

    As you showed, in real life lots of stuff that happens to be working probably shouldn't be. Many a time i find myself reading through old code and saying to myself something along the lines of "OH F*ET!$%*Y HOW THE H*U$!(&Y DID THIS PIECE OF &$!(&!Y% EVER WORK TO BEGIN WITH?!!". Something l

    • I certainly hope, though, that it didn't sound like I was being too critical of your reasoning. You had a great post.

      I'm concerned about the God Object comments, though. I think it's easy to create God Objects with roles and to fundamentally misunderstand OO, but God Objects are less of a concern (I think) with roles. For example, with Test::Builder generating TAP and providing the ability to share the TAP generator, you suggest that these are behaviors which can be separated by delegating to a TAP gener

      • Because you can always implement $customer->save in terms of a well factored interface, but going the other way is much harder.

        The interface that T::B would present is just one facet (albeit a very important one). It used to be that the tradeoff was too much java style boilerplate or a god object, but Moose's handles feature lets you have a nice interface on the outside and flexibility without needing combinatorial explosion on the inside.

        The point is that for 99% of the usage you can still use T::B because that "too much" is handy, but when you want to output a differfent test format or output TAP without T::B.

        But note that I'm also not saying that the remaining 1% of the use cases justify another API. That's just an added bonus. The real benefit is that a clean separation is forced that makes such code generally last much longer, which would mean that developing a better T::B would be a much smaller effort than developing a full stack.

        Isn't that pretty much the same reason for TAP::Parser's design?