The way i've designed the code optimizes memory consumption, though that's merely a side effect of the chosen design. Loading in all of the functions would be a waste of memory if i only have to use 3 of them (out of currently 15 -- more arriving all of the time).

As for putting all of the functions in the server module, that would make it totemically long, and i would much as rather not have to scroll through 500 lines of junk to find out that i missed a parenthesis somewhere. On the level of coding it is an optimization, because i don't have to waste a lot of time looking for the problem.

One of the major reasons i'm going this route however is it's extensability. If i need to do something else all i have to is add a function to a directory at a later date. If i find code that's in a lot of other functions it might be worth my time to farm it out to a new function so that the other modules do one thing, do it well, and no more (which is usually a Good Thing(tm)).

As for using the eval version versus do, require checks to make sure that the module has not already been loaded by Perl previously. This not only saves time but it also can point out programmer error (as above shows).

i'm not trying to be harsh or rude here, it's just that i have had all of these ideas (at one point or another) as they are good ones. Currently i'm working on a project that i've been working on for about 2 years now. i'm not going to tell you what designs i had for some of my earlier attempts as some of them were absolutely pitiful. i think this approach is a step in the right direction because the flexible, extensible design allows me to do very complex things that i would not otherwise be able to easily do.

jynx

No offence taken. And good point about require. I'm still not convinced that having each function in a separate file is a good way to lay out your code on the programmer level, but whatever works for you.

A massive flamewar beneath your chosen depth has not been shown here