http://qs1969.pair.com?node_id=650816

2xlp has asked for the wisdom of the Perl Monks concerning the following question:

I've got an OOP project that has a superclass
package Language; 1;
and many variants
package Language::English; 1; package Language::French; 1; package Language::Italian; 1;
I need to have a unified function in superclass that can figure out which SubClass is most appropriate
package SuperClass; sub derive_subclass_for_word { my ($word)= @_; # test against a regex found in each language, or something like tha +t my $language; return $language; } 1;
and each of the subclasses would have some standard interface , or make regext available, etc...
The questions I have are this: suggestions?

Replies are listed 'Best First'.
Re: Registering Subclass Modules via Plugin
by dragonchild (Archbishop) on Nov 14, 2007 at 18:45 UTC
    You're looking for a factory. There are a number of solutions out there - Module::Plugin is a good one. Catalyst does something similar. Alternately, you can do what Excel::Template::Factory does.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      factory pattern indeed - i'm actually porting a python module i wrote into perl

      thanks! I'll check out those packages for pointers- question though, do you recommend Module::PluginFinder or Module::Pluggable ?
        I don't have a recommendation. I'd use whatever Catalyst and DBIx::Class use as the devs for those distros are pretty much on the ball.

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: Registering Subclass Modules via Plugin
by philcrow (Priest) on Nov 14, 2007 at 19:12 UTC
    I think a factory is for when the caller knows what they want. Your case is different.

    I find out which subclasses are available by scanning all or part of the @INC path list for modules in a given namespace. I do this once, as the app starts. Note that big @INC scans can be time prohibitive. In that case, I look to see which directory my parent module lives in by checking %INC, then look there for my children, making the big assumption that they get installed to the same place as the parent. It works for Bigtop's tentmaker.

    Phil

    The Gantry Web Framework Book is now available.
      Thanks Phil- thats exactly what I want to be doing, and an assumption that I'm 100% ok with making.

      I just went though Tentmaker, and pulled some ideas. Unfortunately you're using File::Find so I can't do the same-thing (i wish though!). This is for an app running under mod_perl, and File::Find is a PITA when it comes to memory on that platform.
Re: Registering Subclass Modules via Plugin
by sundialsvc4 (Abbot) on Nov 15, 2007 at 02:50 UTC

    I agree with the essential sentiment that "you are looking for 'a factory.'" And let me now explain just what I am talking about here...

    The essential common-sense notion of "a superclass" (tah-daah! ooohhh... ahhhh... wowww....) is that, with such a thing, I am able to exploit commonality. In other words, with such a concept I will be able to apply more-or-less the same effort, once, toward "doing whatever it is I need to do" with ... "English, French, and Italian, all at the same time."

    ("After all, they are all 'languages,' right?" Indeed. "And so it stands to reason that most of whatever I am doing ought to apply equally to 'all languages?'" Indeed.)

    This goal of "exploiting commonality" is, "indeed," 'a worthy goal, to be sure.' But if we look at it more closely, we see that it is an entirely separate goal from the very-specific second requirement that you speak of: "figuring out which (human language) is 'most appropriate' for me."

    Ahh, yes... There's 'the rub.' The question is not, "how easy was this thing for the manufacturer to build," but rather, "how appropriate is this thing to what I want to do?"

    It is, after all, a separate and distinct problem from the problem that we intend to solve through the mechanism of classes and superclasses. That concept will be quite-useful in building the various classes (through the economy of effort), but not-at-all useful in choosing between them!

    That concern, namely the concern of choosing, is the concern of "a 'factory,'" not that of "a class."

    The metaphor is breaking down here quite badly, but the essential idea here is that ... classes and superclasses are intended to economize effort in manufacturing, whereas factories come into play when choosing among the various possibilities that have been 'manufactured.'

    (It may well help to "forget about Perl for a moment, and think about real life!") :-D