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:
- figure out what i need to do - how are files broken?
-
- figure out how i want it to look on the outside - @new_files = break($file_name)?
- try to find out where this could be used otherwise - split on different strings? split in a different way? split file handles? split arrays? split... ? brainstorm, and find out what your data really looks best as, in the context of well-known and well-accepted abstractions
- figure out what is the lowest level i can deal with this
- write the easy interface i wanted in bullet 2, and implement it by using the low level interface, and write the low level interface, both at the same time. This serves as a sanity check for the low level interface, and also gets me what i want
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.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.