Adventures in self-documenting code

Further to my recent work on Params::Validate::Dependencies, I wanted to make the code-refs returned by the magic any_of / all_of etc functions somewhat self-documenting. And I've done it. However, there's quite a bit of boiler-plate in lib/Params/Validate/Dependencies.pm as a result. For example, I had to write:
  if($DOC) { return $DOC->_doc_me(list => \@options); }
four times, and define four almost-identical classes.

Boiler-plate is Bad. So I then got rid of it. Unfortunately I got rid of it at the expense of depending on PadWalker, which is Crazy Shit. Do you nice people think that depending on PadWalker is a price worth paying?

Additionally, I also got rid of some not-quite-reblessing magic by using multiple inheritance. Again, is this a price worth paying?

3 Comments

So I looked over the diffs and in this case, I think the use of PadWalker and MI just may be warranted. The reduction in LOC alone is compelling, and the fact is, power tools exist for power users, who know when to use them in the right places.

Hell, the fact you're questioning it at all gives me even more confidence that it's the right thing - it means you care about the sorry sod who might have to debug or maintain it down the road.

If that sod was me, given what this code is and what it does, I think I prefer your Crazy Shit to the previous code.

While I'd prefer to see more explanation in comments, I don't have a huge problem with the use of PadWalker.

I dislike the MI though: particularly if it is just for one method, I'd much rather delegate (with some magic to inject the delegation to avoid code duplication, if needed); in my own code, I'd probably delegate even for many methods.

Leave a comment

About David Cantrell

user-pic I'm in yur test resultz analyzn yr failz