On 11 May 2010 16:58, Stevan Little <[email protected]> wrote:
> <opinion> Overloading in general is a bad idea and is too often abused.
> </opinion>
...
> 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.
That said, this *is* a part of Perl, and because CMOP tries to be faithful Perl
Hypothetically, just because CMOP supports it it doesn't mean it's a
good idea, but it would be nice if it the handling of this stuff
wouldn't be broken. Currently people using overloading can't use
Class::MOP reliably.
The tricky part is that Perl's representation of overload methods is
truly disgusting. Some of them are actual methods, but some of them
are scalar references.
I would be in favour of a patch that would encapsulate this bit of
nasty with as little crap/confusion as possible, and otherwise
represent overload methods as just methods with funny names, which is
really what they are.
> 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).
...
> 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.
That would only cover one half of the problem.
Taking care of code refs as methods (I believe this is the result of
use overload '""' => "stringify" as oppposed to use overload '""' =>
sub { ... }) would be necessary too.
If this can be done cleanly, without making the existing code overly
ugly and confusing (it's already a little hard to follow because stash
handling is so ugly) then I would be in favour of a patch that handles
both these cases, or just the case that is necessary without
Sub::Name'ing your overload methods.
