Everyone seems to be asking "Why do you want to be able to do this?"... Well, I would ask "Why would you not want to be able to do this?". Right now I'm doing it manually anyway... :)

Obviously, if you find it useful carry on doing it - I certainly don't think it's evil :-)

However, if I was working in a team where people were regularly calling methods as Class::method($self) rather than $self->method I would immediately stop and spend some time teaching them some more about how perl works. The two are not equivalent, and using the former to call OO code is almost always a bad idea.

Class::method($self) calls a subroutine method in package Class, and passes $self as the first argument.

$self->method looks at the package $self is blessed into, uses this to find method in the inheritance hierarchy and execute it, passing $self as the first argument. Perl also keep enough context around so that we can call SUPER:: in method if necessary.

By calling Class::method($self) we are:

• explicitly breaking encapsulation by saying that method is implemented in package Class - setting yourself up for future problems if you push the method into another class during refactoring.
• not treating $self as an object

To me this is the moral equivalent in perl of, for example, doing pointer arithmetic to find a slot in a C++ object. Protecting against this kind of inappropriate usage is best done by educating developers (or hiring new ones), rather than by adding extra code.

I don't worry about it in the same way I don't worry about people using Data::Dumper to get at my objects state. If somebody is that foolish they deserve all they get :-)

I will happily argue for checking of method arguments - since this can make design decisions explicit. However, for me, calling object methods as methods, rather than subroutines, is a matter of correct use of perl and shouldn't need explicit checks.