in reply to Re: Loading a different Module depending on the Configuration
in thread Loading a different Module depending on the Configuration

hmm,

the idea is to have the actual methods and whatever way you store and fetch stuff plugable, so, down the line I can say, 

 
my $scheme = 'FooSQL';
my $h = TheDb->new($scheme);

[download]

And, perhaps someone else, with a different setup and wants will go:

 
my $scheme = 'DB_File';
my $h = TheDb->new($scheme);

[download]

having all the subclasses loaded at the same time would be incredibly wasteful and useless, since I may not know exactly what DB (or subclass module) is there.

This may seem like more work, why would you have n ways of doing the same thing? Well, you may not have a Spiffy SQL and are OK with using a plaintext solution, knowing some performance woes.

This is for a very mature, stable app, not a quick 15 minute script.

-justin simoni
!skazat!

Replies are listed 'Best First'.
(jeffa) 3Re: Loading a different Module depending on the Configuration
by jeffa (Bishop) on Sep 27, 2001 at 20:22 UTC
    This is for a very mature, stable app, not a quick 15 minute script.

    <sarcasm>Heh, he he, ha HA! HAHAHAAHA!</sarcasm>

    Seriously, what school of Software Engineering did you graduate from - do you really think that using a Factory Pattern is something that a script kiddie would come up with? It's a very common Design Pattern.

    i do appreciate your desire to write your app 'The Right Way' - i really do, but sounds to me like you are too worried about 'false optimization' - imagine a interstate with a lovely 8 lane bridge that has been carefully constructed to maximize car flow ... only to be followed 2 miles down the road by a one lane bridge that you have no control over - that's false optimization.

    You have a lot of good clues here on this thread on how to solve your problem - take these ideas and run with 'em! Sounds to me like a factory pattern, or as dragonchild called it, a 'polymorphic constructor' - is a pretty valid idea for this problem. If you don't like that - then you might want to rack your brain against an Abstract Factory.

    But as for being concerned about loading subclasses that won't be used for a particular run of the app - do you _really_ need to concern yourself with that? And even if you do - doesn't that sound like a job for the _next_ version? (nudge, nudge) ;)

    jeffa

[reply]

      Seriously, what school of Software Engineering did you graduate from

      I'm 20 years old and going for a Bachelors in Fine Arts, I think I'm doing pretty well, I've never taken a CS class and I barely passed Algerbra 2 in High School. I have interesting ways of solving things.

      It seems to me that loading up each and every module that *could* be used is wasteful, also since I want to allow n number of different DB schemes.

      I'm going to solve this problem in a similar manner as AnyDBM_File does, since it pretty much has the exact mechanism that I'm looking for.

      I probably should have mentioned that each scheme to do the dirty work is a bit more complext than fetch() store(), there's also searches and thingies that actually print and return interesting things.

      do you _really_ need to concern yourself with that? And even if you do - doesn't that sound like a job for the _next_ version? (nudge, nudge)

      This could theoretically be the next version, although this particular app version has been going on heavy development since the .0 release last July (2000) . There is absolutely no way I'm starting from scratch, alone on a 1 meg program written in Perl

      I talked to my accountant (my wallet and my college bill) and thought that if I could release, say a totally Open Source and Free version of this particular program, making the Base Module LGPL'd, have a plain text version GPL'd and have, say a Postgres or MySQL version proprietary (ie, sell the SQL version) I could help myself out, and at the same time, make the transition relatively painless, if I decide to just go with a SQL backend. A pluggable achitecture will also allow other developers to create their own solutions and that'll keep the vitality alive for the program itself.

      I may draw pretty pictures all day, but you get a lot of thinking done in the process :)

       

      -justin simoni
      !skazat!

[reply]

In Section Seekers of Perl Wisdom