Re: When is a module too minimal?
by hv (Prior) on Jul 19, 2006 at 11:18 UTC
|
Your question seems rather to be "when is a script too minimal?" If the content of the module is sensible, then I have no problem with an entire script looking like:
use MyModule;
MyModule->go;
I see no reason why you'd want to require that a script show some minimum complexity.
The key though is that the module should not just be a dumping ground for the stuff in the script - it should follow the normal principles of module design, so that each method/function should perform a single clearly defined function that is well described by its name, and the collection of methods should be related to each other in a way clearly encapsulated by the module name.
If the module does what it should, and if one of its methods does everything the script wants and needs, then that's an ideal situation.
Hugo | [reply] [Watch: Dir/Any] [d/l] |
Re: When is a module too minimal?
by gellyfish (Monsignor) on Jul 19, 2006 at 11:15 UTC
|
To me that is perfectly fine, there's a lot of software which is a tiny driver program over some library. You probably do want to consider whether you want a single or multiple modules though: separating presentation, application and business logic makes reuse of the components easier.
/J\
| [reply] [Watch: Dir/Any] |
Re: When is a module too minimal?
by rodion (Chaplain) on Jul 19, 2006 at 12:19 UTC
|
So, as hv suggests, you're asking when does the Module do so much that the script is too minimal.
I agree with him that a script which has nothing in it but a single call to a module is fine, as is one that just has config info. However, I think your intuition that someting is odd might be coming from another source. You're putting code in the module so it they can be used in more than once. The things that are different from case to case aren't code, however, they are data. Thus the task could also be organized as a single script which selects among configuration as one of its actions. It could take the config data from a hash in the script, a singele config file with sections to choose from, or a set of distinct config files.
In that model, you put the code at the top level of attention, with the config below it. That may be clearer, or it may not, and that's one of the choices you make in deciding what "simple" means in this case and it's context.
Putting the config info conceptually below the code is an organization worth considering (and maybe rejecting), but I think that's what's tugging at the intuitions in the back of your head. | [reply] [Watch: Dir/Any] |
Re: When is a module too minimal?
by philcrow (Priest) on Jul 19, 2006 at 12:42 UTC
|
I don't just think it's OK to have a trivial driver, I think it is the goal. See for example pod2html. The one installed with my Perl is 144 lines. Of those, 137 are POD and 2 others are blank.
By carefully factoring code out of the script into modules, you allow other script and module authors to leverage your code. If you leave everything (or anything) in the script reuse becomes harder, especially if you don't use many subs.
I think of a the ideal script as a mapper between command line arguments and one or more modules (not that I always achieve the ideal).
Phil | [reply] [Watch: Dir/Any] |
Re: When is a module too minimal?
by Ieronim (Friar) on Jul 19, 2006 at 13:03 UTC
|
#in the file Acme/Helloworld.pm
package Acme::HelloWorld;
use warnings;
use strict;
sub new {my $class = shift; bless {}, $class }
sub helloworld { print "Hello world!\n" }
1;
#in the file helloworld.pl
use Acme::HelloWorld;
my $h = Acme::HelloWorld->new();
$h->helloworld();
And CGI::Application enforces you to do such things. There is nothing bad in such a way—the worst thing about it is that the executable file does not contain any information about what it really does :)
I don't know your certain case. IMHO if you can do different things (e.g. create different HTML pages for different projects) by modifying only 'config' lines in your script—it's good. Your script is simple enough and your module is complicated enough to fulfil your needs. If you can create only one certain page—there is nothing bad in it, as the page is finally created and from this point of view there is no difference how did you produce it.
s;;Just-me-not-h-Ni-m-P-Ni-lm-I-ar-O-Ni;;tr?IerONim-?HAcker ?d;print
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: When is a module too minimal?
by Ovid (Cardinal) on Jul 19, 2006 at 13:56 UTC
|
As noted, there's nothing wrong with what you've done. Here's a bit more for you to think about.
You've written a class with one constructor and one method. A class has a dual role. First, it must provide everything it needs to provide. That is to say, it must be "complete" and that tends to increase its size. However, a class is also frequently an element of code reuse and then it should be as small as possible. Thus, you have competing pressures on the classes and this can cause difficulties with design.
If you have a small class which does everything you need to do, you really don't have as much worry about that competing pressure and this is a good thing. And if you're really, really crazy, you can read a bit more about the problem and strengths and weaknesses of various solutions to it.
| [reply] [Watch: Dir/Any] |
Re: When is a module too minimal?
by Fletch (Bishop) on Jul 19, 2006 at 12:15 UTC
|
Everything should be made as simple as possible, but not one bit simpler.
–Albert Einstein
| [reply] [Watch: Dir/Any] |
Re: When is a module too minimal?
by Arunbear (Prior) on Jul 19, 2006 at 21:17 UTC
|
... and the object would just figure out what mode it was in from the query string and do ... everything. The object will have its own CGI object, its own HTML::Template object and so on.
Are you are converting a CGI script into a module? If so why not just use CGI::Application i.e. why do you have start from scratch?
| [reply] [Watch: Dir/Any] |
Re: When is a module too minimal?
by bsb (Priest) on Jul 20, 2006 at 02:30 UTC
|
| [reply] [Watch: Dir/Any] |