Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

gnat (29)

gnat
  (email not shown publicly)

Journal of gnat (29)

Wednesday June 20, 2001
02:34 PM

Project: Better Interfaces

[ #319 ]
There are some modules in Perl that provide useful and important functionality, but which have crappy interfaces. I'm thinking of File::Find and File::Spec as two cases in point, but I'm sure you have your favourites too.

It'd be informative to design better interfaces to such modules. Think to yourself: if I was writing File::Find today, what would I want it to do? In some cases you'll be able to implement your new interface as a wrapper on top of the old module, but I suspect that some things will really require reimplementing the module from scratch.

And obviously the new modules couldn't have the same name as the old ones--they'd have a different interface and so are obviously incompatible with existing code. But there's no law that says people can't install better versions of core modules that are shipped for historical reasons only.

Are some of the modules really this bad? Yes. Take File::Find. It's been somewhat modified lately, but the code in that module used to be in find.pl, shipped with perl4. In fact, File/Find.pm used to be just "require 'find.pl'". find.pl was designed before we had public interfaces. Before we had tie. Before we had objects. Before we had Exporter. Before we had references. Before we gave two monkey nuts about portability. Perhaps, just perhaps, there's a better way to do what it does, or even better things it could do. They might not involve objects and ties and overloaded operators, but they will probably involve a simpler interface and making easy things easy.

--Nat