[Pdx-pm] Musings on operator overloading (was: File-Fu overloading)

[Eric Wilhelm]

# from Aristotle Pagaltzis
# on Sunday 24 February 2008 07:00:

Note that I didn't have to type the 'or die' message, and that the 
croak() built into File::Fu includes the filename in the error message.

>>     my $fh = $file->open;

>      open my $fh, '<', $file or die "$!\n";

I think there is a usefulness in having the filename be an object.  This 
means it then has to at least be able to stringify.

And then we're left with the perl5 overload issues.

>I’ve seen Path::Class used extensively in the context of
>Catalyst, and one thing that struck me is how often you must
>explicitly stringify, because there’s this tension between APIs
>that expect filenames as strings or objects of certain kinds, ...

Well, they are like strings for anything that doesn't understand them as 
path objects.  If you're passing them to code that wants a string but 
croaks if ref($str), the bug is in that code.

>it makes the spot that does something unusual explicit about its
>unusualness 

By that principle, shouldn't all lines of perl start with an "unusual" 
keyword?

>But note that in all of these examples, it is very much
>self-evident what the meaning of an overloaded `+` would be...
>When you leave the broader domain of mathematical and “para-”
>mathematical abstractions behind and start to define things like
>division on arbitrary object types ...

Well, I'm not "defining division".  The '/' as a directory separator is 
just a "slash" character.  The operators don't want you to think of the 
operands as numbers, and the reader who can't accept that might as well 
complain that matrix multiplication is non-commutative -- that's just 
the way the convention is defined.

I see what you're saying about the scoped overloading, but I don't think 
its actually as useful as objects in this case.  If the conventions I'm 
defining for manipulating these objects with operators don't work for 
you, I would love to hear alternatives.  (I've considered '|', '^',
'&', and combinations involving '<<', '>>', but I don't think I can go 
below '<<' because I'm using & as the map(), so it's pretty slim 
pickings to choose a set with the correct precedence.)

The feedback on operator overloading has been mixed.  At present, 
the '+' opinions outnumber the '-' ones, so I'm at least certain that 
I've created sufficient controversy.  Try the method API?

--Eric
-- 
Issues of control, repair, improvement, cost, or just plain
understandability all come down strongly in favor of open source
solutions to complex problems of any sort.
--Robert G. Brown
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------