in reply to Re: Re: The costs of packages
in thread The costs of packages

Actually, the factory approach does not require mass pre-declaration and doesn't need to load anything that you don't use, so it's the best approach if you want to stick with the multiple packages approach. The factory method here would figure out the package name dynamically and then do a require for it, instantiate it, and return it.

I still think you can do it without multiple packages though, if they all share the same methods. You only need multiple packages if every package has different methods.

Replies are listed 'Best First'.
Re: Re: Re: Re: The costs of packages
by BrowserUk (Patriarch) on Sep 16, 2003 at 06:36 UTC

    Could you put a little flesh on those bones for me please? A brief example of the factory package and how to use it would be good.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
    If I understand your problem, I can solve it! Of course, the same can be said for you.
[reply]
      Here is an example written using Class::Factory .

      In my factory (Audio::Info), I register all available types (look for register_factory_type, Audio::Info::Ogg and Audio::Info::MP3 for now) upon compilation, and each type is loaded upon first use (I could've done add_factory_type instead, which would load each available type upon compilation of Audio::Info).

      I hope that demonstrates it well enough.

      MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
      I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
      ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]

        Thanks for the examples PodMaster.

        I *think* that the problem with this (for my application) is that it requires that each of the subtypes exist as seperate files? As I (belatedly) outlined elsewhere, the application requires that the packages be generated on demand (from information stored in the top level package, which itself is autogenerated from a set of large C header files). It would be possible to generate the hundreds of small .PM files directly, but the volume would make this messy and difficult to manage.

        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
        If I understand your problem, I can solve it! Of course, the same can be said for you.
[reply]

In Section Seekers of Perl Wisdom