in reply to Modulinos and CPAN-appropriateness

The C in CPAN is "Comprehensive". :)

The idea of a modulino is that there is a little run routine which you can use by default, but someone else can still use all of the subroutines and supporting code from the module if they like your application but want it just a little bit differently. They use your modulino but subclass it to change the run() subroutine and to override the parts they want to change.

Do do any of that they need to be able to get it, and that means putting it on CPAN. So, upload! :)

(Oh, and it's just Mastering Perl :)

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

Replies are listed 'Best First'.
Re^2: Modulinos and CPAN-appropriateness
by krazyk (Beadle) on Nov 21, 2007 at 00:08 UTC
    "They use your modulino but subclass it to change the run() subroutine and to override the parts they want to change."

    This implies that the modulino is object-oriented ("subclassing" and "overriding"). Now, I'm not sure that you intended this statement to be taken that literally since some of your modulino demonstrations featured functional interfaces. However, it brings up some interesting considerations...

    In Mastering Perl, you introduced "Modules as Programs" using a purely funcational module. In DDJ - Scripts as Modules, you introduced modulinos, recommending an OO style consisting entirely of class methods. This solely-class-method approach supports easy inheritance and overriding, but seems slightly less versatile when it comes to re-use of subroutines. For example, say Modulino::A has "run()" and helper function "buy()" so that buy() influences what run() does. Suppose that buy() is useful enough to be exported by Modulino::A for potential re-use. Suppose that Modulino::B wants to do exactly what Modulino::A does in its run method but to use a different buy()ing algorithm. If buy() is to be usable outside the modulino, it might be cleaner to design it as a plain function instead of a class method. Then buy() could be called as a regular function instead of PKG->buy()...
    Read more... (2 kB)
    Now we can cleanly inherit and override as well as export. This mixed interface style seems to me to be the most versatile way to build modulinos. The only problem is that ugly symbol table modification, but it would probably happen rarely and could be automated and abstracted by another module (which is why I'm so interested in finding the optimal pattern...I'm considering developing a module to aid in the construction of modulinos). What do you think?
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom