in reply to Should Modules Do I/O?

This kind of dilema normally raises questions about how the problem could be broken down into better interfaces.

Lets pretend I'm writing your module. This is what I would do:

What this yields: I usually give 120% effort for writing a simple thing, but when we look at it a while later, the first solution is about 300% more work, while additions to this solution takes about 150%, a pretty good figure (imaginary, too... i don't know how big the difference actually is, i just feel that there is one).

anyway, i hope this helps.

My conclusion: make two modules. One with an easy interface, and one with a flexible one. =)

Update: I'd like to say that one of the things that /reaaally/ annoys me btw, is that most of the parsing and archiving tools on the CPAN take care of files for you so that it'd be "easy". Most of the stuff that handles that is done, and my typical usage is for things that havne't been done. I needed to parse many formats, and compress on the fly, and what not, on streams, and scalars, with callbacks, without, and so on. Normally i either look into the guts of the module and just wait till my code breaks when the module is updated. Sometimes i just give up.

Modularity is not worth anything without reusability, and in fact, to encapsulate decisions which are not yours to encapsulate (but rather, a FileManager's module responsibility), in a module, makes it much harder than if it were not modularized.

-nuffin
zz zZ Z Z #!perl