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.
|