|Just another Perl shrine|
To use a module...or not.by BrowserUk (Pope)
|on Jul 24, 2004 at 02:16 UTC||Need Help??|
At Re^3: sorting a complex multidimensional hash, I took some gently stated critique seriously and tried to find a better way of expressing the ST and GRT versions of that sort. Then later, Ven'Tatsu's post made me look for a CPAN solution.
If you like the idea of encapsulating your ST sorts (or the GRTs & Orcish Manouvers), then there is an existing module that will do this for you Sort::Maker.
It's an impeccably pedigreed module; cleanly coded; well documented etc. The problem is, it took me much longer to work out how to write even a simple ST or GRT using it than writing them directly. The resultant code requires just as much typing and (IMO) is no clearer or easy to maintain that the usual map-sort-map version.
I then spent many hours trying to work out how to apply it to Re: sorting a complex multidimensional hash and got nowhere. I simply couldn't work out how to use it to this sort, either the ST or the GRT version. Both of my hand coded versions took under an hour each to write and test.
There is nothing wrong with the module, not it's interface design, nor it's documentation. The problem is that even for relatively simple versions of either style of sort, you have to pass all the information required to perform the pre- and post- processing of the data, plus the comparator, plus the direction of the required sort into the module as small, discrete chunks of code.
I find it's just much easier to see what is going on, and what is going wrong, and to test and spot where they are going wrong, when I write that code in the usual manner, than I do as lots of discrete little bits.
I have similar misgiving with callback interfaces typified by things like the various HTML parsing modules. You're constantly operating one level removed from the place of execution. If what you code works first time, they're great. It's when I get a problem, make a mistake, that I find myself having to bypass the documentation and going to the source to try and work out what and where the problem lies. At that point, the main benefits of using a canned solution tend to go out of the window.
Even if I succeed in making the combination work, if the code needs modification at some later stage, I (or the whomever has to maintain the code), has the same problem of trying to understand the combined effect of two separate pices of code, rather than one.
I am the only one that feels this way?
How would you simplify/clarify the coding of ST?