Chris,
On May 10, 2010, at 10:03 PM, Chris Weyl wrote:
Hi all --
A while back I noticed that when I tried to use namespace::autoclean
and overload in the same package, my overloads would be purged by
namespace::autoclean... Resulting in a non-optimal situation.
Digging into it a bit more it became quickly apparent that this was
happening because overloads weren't being recognized as methods by
Class::MOP. I wrote a little hack that would "fix" this in
namespace::autoclean; it was pretty hackish, and ended up redoing it
(a little better, I hope) in MooseX::MarkAsMethods.
Sooo....
1) Am I crazy in thinking that overloads should be, if not treated as
methods, then at least tracked/managed by CMOP as methods (or
something similar)?
Yes, you are crazy ;)
No, this is not likely going to happen in CMOP.
<opinion> Overloading in general is a bad idea and is too often
abused. </opinion>
And even when it is not abused, it can often times be very confusing.
Take the case of Math::BigInt, it is a custom representation of a
number, of course it should overload the standard math operators. And
when you see this:
my $baz = $foo + $bar;
You know that $foo, $bar and $baz are all numbers (even if one or more
is a Math::BigInt underneath). Now take the case of DateTime, it
overloads the math operators to perform date math. And when you see
this:
my $baz = $foo + $bar;
You have no idea what $foo, $bar or $baz are. They could be numbers,
they could be Math::BigInt instances, they could be DateTime
instances. Who knows!
Now in a strongly typed language, this might not be that bad since the
compiler would have enforced that $foo, $bar and $baz are indeed
compatible, but this is Perl so ... nope didn't happen.
While CMOP does it's best to try and create a nice Perl-ish meta model
that integrates cleanly with the core or Perl, it does reject some of
the more fragile and ugly aspects of Perl in it's own core and
overloading is one of them.
2) How does CMOP determine what is a method and what isn't?
CMOP requires that a method be defined inside a given package for it
to thought of as a method of that class. We determine this fact by
poking at the underlying stash name of the CODE reference to make sure
it matches the package name. This is how we ignore functions exported
by other modules such as List::Util, etc. and not accidently treat
them as methods.
The reason overloaded methods fail to pass this test is because the
methods are created inside the overload.pm package and the stash is
not altered when they are imported (this is possible to do using the
Sub::Name module).
I'm certainly willing to try my hand at a topic branch if #1 makes
sense, but it seemed like a good idea to ask for advice (and a sanity
check) here first :)
No thanks, but you might petition p5p with a patch to make overload.pm
behave properly when importing methods. If you can get this accepted
then CMOP should Just Work.
- Stevan
