Re^5: Private Methods Meditation

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"™

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Comment on Re^5: Private Methods Meditation

Replies are listed 'Best First'.

Re^6: Private Methods Meditation
by diotalevi (Canon) on Jul 20, 2004 at 01:35 UTC

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( ... ).

[reply]
[d/l]
[select]


Perl-Sensitive Sunglasses
	PerlMonks