in reply to Re^2: Module Bloat and the Best Solution
in thread Module Bloat and the Best Solution

There are at least two major problems with that code and possibly as many as four or more.

Don't allude to them, name them.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re^3: Module Bloat and the Best Solution

Replies are listed 'Best First'.
Re^4: Module Bloat and the Best Solution
by dragonchild (Archbishop) on Nov 12, 2007 at 18:07 UTC
    Chromatic already mentioned overloaded stringification. The naive solution posited only returns the stringification, period. Furthermore, the naive solution posted doesn't retain order while the solution provided by List::MoreUtils does.

    An additional feature of L::MU's uniq is that it provides a prototype while most variations don't. I thought there was a fourth item, but I could be mistaken in my old age.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

      How is a prototype of just @ a feature?

      lodin

        Because it allows me to write code like my @foo = map { [whatever] } uniq @arr1, uniq @arr2; With the prototype, this parses to uniq(@arr1), uniq(@arr2);. Without the prototype, this parses to uniq(@arr1, uniq(@arr2));. See the difference?

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
        Prototypes aren't bad. They're just a heck of a lot of rope by which one can hang oneself. I certainly wouldn't want to use them, but they have their uses. Kinda like symbolic references. There's some code that can't be written without them (like Exporter), but that doesn't mean most people should use them.

        My rule of thumb is unless you know why you should never use them, you should never use them.


        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
        The crux with prototypes is that they aren't, as you know. But some constructs aren't possible without them - see Embedding a mini-language for XML construction into Perl (and Re: Perl module for RELAX NG?). Those are the only "prototypes" I use now and then - function "prototypes".

        --shmem

        _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                      /\_¯/(q    /
        ----------------------------  \__(m.====·.(_("always off the crowd"))."·
        ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Re^4: Module Bloat and the Best Solution
by chromatic (Archbishop) on Nov 12, 2007 at 17:32 UTC

    What if some of the elements in the array are objects with overloaded stringification?

      You mean something like

      print Dumper \@list; $var = ( [ 1,2,3 ], [ 4,5,6 ], [ 1,2,3 ], [ 4,5,6 ], [ 1,2,3 ], );

      From which List::MoreUtils::uniq will render

      use List::MoreUtils qw[ uniq ];; print for uniq @list;; ARRAY(0x194ac18) ARRAY(0x194ac54) ARRAY(0x194ac90) ARRAY(0x194accc) ARRAY(0x194ad08)

      But the required result might be:

      ARRAY(0x194ac18) ARRAY(0x194ac54)

      With the "naive" solution, any attempt to use the stringified reference (or other stringifed value) in the place of that value, is going to throw up an error immediately. Thereby warning you that either the nature of your data has changed and your solution is no longer good enough, or there is an up-stream error that is giving you bad data. With the module solution, you aren't going to get that error until some point later when it will be much harder to trace back to source.

      For simple scalar values, the "naive" solution works fine. And once you start adding non-simple values-- like references--into the mix, it is naive to believe that judging different references to structures containing identical values as distinct, will always be correct. Or even that it would be correct in a preponderance of cases.

      For every scenario where the modules result would be more correct, there is another where it would be more wrong.

      The point is: you have to know your data, and tailor your solution to that data and the required semantics.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.