both interfaces be supported

Providing both seems like YALORC to me. Yet Another Lump Of Reduntant Code,

Your post would make it three

With the interface I describe, the other two interfaces can be trivially derived through subclassing, or just simple procedural wrappers.

That could be done as a part of the module, but I see no value-add in that, as it is equally trivial for the user To Do It themselves, and they can tailor it to their exact requirements, instead of having to work around the supplied interface.

Neither of the other two interfaces can be easily wrapped to provide each other, nor that which I described.

As you acknowledge, these three interfaces can be implemented using eachother. The higher level methods can use the lower level methods. There is nothing redundant there.

Nobody is suggesting that the OP should make one and only one interface available, except you (unless I am misunderstanding your position). Few users will have to "work around the supplied interface" if the interface embodies the common usage scenarios. That is the value-add.

As you acknowledge, these three interfaces can be implemented using eachother.

I did not acknowledge that--I flat out contradicted it.

Neither of the other two interfaces can be easily wrapped to provide each other, nor that which I described.

And I'm not sure how you came to that reading from my post?

Nobody is suggesting that the OP should make one and only one interface available, except you (unless I am misunderstanding your position).

You are not misunderstanding my position. I think that a single flexible interface is prefereable to multiple overlapping interfaces. Adding bloat to a module is detrimental rather than value-add IMO.

If there are common usage scenarios that would benefit from a simpler interface, these should be provided through a separate package that wraps the flexible interface in the same way that LWP::Simple wrap LWP::Useragent and XML::Simple wraps either XML::Parser or XML::SAX.

I'm not into deeply nested hierachies, but two levels strikes a good balance between depth and breadth at all levels.

• It allows the segregation of the code for both maintenance and use.
• It allows the *::Simple documentation to be exactly that, rather than mixing it up with the complexities of the full interface.
• The *::Simple module becomes an excellent "API design" test, and long-term regression test for the primary module.
• It also serves as a "worked example" of both using the primary module and extending it.

  ---

  Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

  Lingua non convalesco, consenesco et abolesco.

  Rule 1 has a caveat! -- Who broke the cabal?

sub get_file
{
  my $self = shift;
  my $filename = shift;
  my $outputdir = shift;

  my $ofh = IO::File->new(File::Spec->catfile($outputdir, $filename), 
+'w');
  $self->get_filehandle($ofh);
}
[download]

The amount of code I get to save by having this in the module is awesome. And, thus, the number of bugs I'll have in this code will be darned few. Approaching zero the second time I use it.

Redundant is writing the above 12 times rather than having a single sub doing it for me.

Agreed.

But what if I want read access? Or read-write access? Or read the file from a pipe?

Of course, you can fix up your sub to deal with all of these things, but then you've reinvented open, which exists, is tested and supported everywhere, and can do all of those and more.

What-if you need to read from a socket? Or you need access to acls? Or security attributes? Or named-pipes? Or...

And if the OP's module also has that same snippet of code? Which is the redundant one?

And Another::Module also has it, but dies if the file could not be found?

And Bother::Module has it, but always, silently, overwrites any existing file?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco.

Rule 1 has a caveat! -- Who broke the cabal?