Re: Module Bloat and the Best Solution

[zby]

For me the solution with module is more readible. It is more in line with our thinking - it says:

• take the 'uniq' operator from the library
• apply it to the list

The other solution says:

• create a hash by assigning 1 to every element of the list
• list the keys of the hash

It requires much greater thinking loop to understand that this is indeed the solution to the problem at hand. You need to think about how hashes are created, and what is listing their keys - with the library solution you only need to think if the 'uniq' sub really does filter unique values out of the list, but the name of the function is mnemonic enough that it's kind of automatic.

[dragonchild]

To further emphasize this point, there are a number of edge-cases that most programmers will never encounter, even in such a "simple" problem as unique-ing a list. For example, undef and "" will both be treated the same way, which may not be appropriate. Two-faced scalars may not be handled correctly. Objects and references will certainly not be handled correctly. A library, on the other hand, can solve this problem without you even needing to know that the edge-cases existed. That is the big win.

(Note: This isn't to say that the library always does it right. The version of uniq() in List::MoreUtils doesn't handle two-faced scalars correctly, but it does handle objects and references correctly, as expected.)

[oxone]

>>A library, on the other hand, can solve this problem without you even needing to know that the edge-cases existed<<

Unfortunately you can never take it on trust that any given library *will*, so it's still really down to you to try and think of all the edge cases, test them, and then possibly fix them. Sounds like your own example bears this out.

[chromatic]

I think you mean "you and everyone else who uses the library and could possibly run into the same bug", which is a rather different point.