Jan 14

After converting Mason 2 to use Dist::Zilla and Pod::Weaver, I am starting to think in plugins and see opportunities for them everywhere.

As just one example, I initially added a cache feature to Mason 2, just because it was there in Mason 1 and seemed generally useful. But now I realize it can be cleanly separated into its own plugin.

There’s no real performance or footprint advantage for those that omit the plugin. What it does do is put all the cache related code, documentation, and tests in a single place. As small as it is, the cache feature touched many of the main Mason modules in some way; now it is all in its own directory. It also makes me more amenable to expanding the feature (e.g. with new parameters or methods), because I’m not worried about disproportionately “polluting” the main code and API.

Of course, deciding what is a plugin versus a built-in feature (plus that third category, a plugin-in-name that really everyone expects to install) is the age-old question. Too many plugins will of course hurt performance, because each one adds a layer of method modifiers, and will also hurt useability and readability. I’m still quite confused about where and how Dist::Zilla performs many of its tasks, and part of that is the sheer number of plugins one needs for a typical installation. It’s a virtual certainty that in my new enthusiasm I’ll over-plugin somewhere.

One Response to “Getting plugin-happy”

  1. Matisse Enzer Says:

    The value of separating some chunk of functionality into its own portion of a code base is, I think, rather high. I have of late been paying a lot of attention to, and evangelizing the notion of Separation of Concerns as something that is worth thinking about at every level of a complex system, the more complex, the more one should consider it. At each component and level, from a method to overall architecture one asks “What are the unique responsibilities of this piece? and how does it collaborate with the other kids?” There is no single right answer. Having good separation of concerns is a huge aid in enabling us humans to understand, manage, work on, and evolve complex systems – we must also pay attention to the system as a whole, after all, all those collaborations produce holistic results, and it is usually those overall results we are most concerned with.

    Side note: I’ve been thinking more late;y about Aspect Oriented Programming as one way of handling the separation of concern problem for cross-cutting concerns.

Leave a Reply

preload preload preload