Re^3: Private Methods Meditation

[hardburn]

sub method2 { my $self = shift; _method1( $self ); }

or am I missing something really obvious in this example ?

Yes. If you don't override _method1 in the subclass, nothing will be called.

[guha]

When I run dragonchild's example above with my modification

Foo::_method

is printed.

QED

[dragonchild]

Let's extend the example a little. What if _method1 isn't defined, but is AUTOLOAD'ed instead? This isn't an unreasonable thing. So far, so good.

Now, let's say that the Foo class inherits from some CPAN module. This is a very common thing. Let's say we're inheriting from CGI::Application.

Now, let's say that CGI::Application adds a _method1() in the next version. Uh-oh. Your code breaks in very mysterious ways.

What if CGI::Application adds dependence on AUTOLOAD in the next version. Uh-oh. Your code breaks again, but in even _MORE_ mysterious ways. (Cause it's not your code that broke, but it sure looks like it!)

Perl6 fixes most (but not all) of these issues, which is a "Good Thing"™

[diotalevi]

A side note. AUTOLOAD is already unreasonable. The only place I expect to find that is in code like Class::Delegation and Win32::OLE where the total of methods cannot be known during compile time.

When I consider this: an object only uses method call syntax when inheritance is intended to be at work. If the author of the subclassed module didn't intend for the _method to be overrideable then it wouldn't be called with -> method syntax. If you intend to call _method and define it privately then you ought to be calling it as _method( $self ... ). Alternatively, if you want to use inheritance internally for your private methods then you have to be explicit about the package: $self->Foo::Bar::_method( ... ).

[hardburn]

So what happens when the method needs to access the class data?