(unless you tie the filehandle but please don't go there).
Why not?

Because tieing a filehandle is even more work that passing in an object or even currying by hand. It's also slow. Finally it has interface issues, if the framework has been written to think in terms of logging to a filehandle it might be tempted to do

print $log_fh "doing something..."; if (do_something(...)) { print $log_fh "suceeded\n"; } else { print $log_fh "failed\n"; }
which is going to be rather unpleasant for anyone who wants to tie the filehandle and maybe manipulate the messages. You could decide that a log message ends with a \n and then you have to buffer stuff inside your tieing object but that rules out the possibility of multiline messages. It's just not nice.

tie is a horrible hack to get around the fact that Perl's fundamental data structures are not objects and thus cannot be substituted for by a user defined object implementing a compatible interface. No other language has tie because no other language needs it. So in other languages you can create something that can pretend to be both as a hash and as an array but in Perl we have to choose one or the other.

There is nothing natural about having to implement TIEHASH, FETCH, STORE, DELETE, CLEAR, EXISTS, FIRSTKEY, NEXTKEY, SCALAR and UNTIE just to create a case insensitive hash. In another language you'd just inherit from hash and override the fetch and exists methods.

There is one good thing about tie and that is tied scalars because in this case you are effectively taking control of the assignment operation. Most languages allow you to control the behaviour of values, I think Perl is unique in allowing you to control the behaviour of variables but that's it.

As for the usefulness in general of currying, of course nobody uses currying for adding 2 in real life however if you want to make full use of map, grep, reduce, fold etc. then currying allows you avoid lots of closures. Anything that can be done with currying can be done with closures and many of the most common uses of closures are no more than just currying. So it's just a nice way of compressing

sub {some_func($this, $that, @_)}
down to
some_func_c($this, $that)
less typing means less typos. It's only a small saving but it eliminates lots of punctuation which gets it some bonus points.

In reply to Re^6: Near-free function currying in Perl by fergal
in thread Near-free function currying in Perl by tmoertel

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.