Sort-Flat reviews

cpanratings
 

RSS | Module Info | Add a review of Sort-Flat

Sort-Flat (0.18) *

In its current implementation, this module is worse than worthless. It solves an exceedingly trivial problem with an excessively brutal tool and pays no mind to concerns of flexibility and user choice.

It is understandable that someone who wants to do a lot of case insensitive sorts might want a less awkward way to specify this, than by spelling it out explicitly every single time. Unfortunately, the sort() builtin doesn't have a prototype custom Perl code can emulate.

So this module runs a source filter on the code to drop a case insensitive comparison block on all block-less sort calls.

This makes it useless in production environments, because source filters may break code in subtle ways and conceil what the Perl compiler actually sees from the programmer.

There is also no direct way to exclude specific calls from this module's treatmeant, only awkwardly, by adding a { $a cmp $b } block yourself. Fortunately, recentish Perls will recognize its do-nothing-extra nature and do a straight, blockless call -- but this wasn't always the case.

Why not simply export a sorti() routine into the user's namespace? The added verbosity of one character can't be a serious problem; personally I would even consider it desirable, to remind a later reader of the code that this isn't your standard sort happening here. It can't really matter that you can't tell whether a coderef passed in $_[0] was meant as a sort function or was part of the data to be sorted, either -- if someone is using a sort function, they already have a block, so they can just call the normal sort() and put in case insensitivity themselves.

The only reason I could at all think of is that it adds an extra function call, which might rub a microoptimizing programmer the wrong way -- but then just exporting an nc() function (for "no case") to be used as in "sort nc @list" would solve that problem. Also, the sort function used here doesn't cache the transformed strings it compares, which is likely to cost a lot more cycles than the intermediate function call and return value copying if a lot of data is being sorted. If performance is really the goal, there are better choices:

* One would be to use a B:: module to modify the optree, which, much like the source filter, modifies the code before it is executed, except that it's not nearly as easy to break as source filters. Of course, it's also much harder to write such a beast.
* The other would be to write some XS, which I'd prefer -- it's then possible to transform the strings being compared as they are being compared, character by character, so the transformation can be aborted as soon as the first difference between strings is found. In many cases, this means only the first character is at all transformed.

My final gripe is with the name. Sort::Flat makes me think it tries to solve some issue relating to nested data structures. In fact, I checked it out when it appeared in the Recent Uploads list *twice* so far, forgetting what it was about after the first time, because I wanted to see what "flat sorting" meant. A much better name would have been something along the lines of Sort::NoCase.

At least the documentation is more than ample and takes the time to describe the module thoroughly. :)