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
| [reply] |
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] |
| [reply] |