|
Re^2: Private Methods Meditation
by guha (Priest) on Jul 19, 2004 at 12:27 UTC
|
sub method2 { my $self = shift; _method1( $self ); }
or am I missing something really obvious in this example ?
Or for better general safety, mark the privates to make their names unique.
package Foo;
sub _F_method1 { print "Foo::_method\n"; }
sub method2 { my $self = shift; $self->_F_method1; }
package Foo::Bar;
@ISA = qw( Foo );
sub _F_B_method1 { print "Foo::Bar::_method\n"; }
package main;
my $foobar = Foo::Bar->new;
$foobar->method2;
update: s/exclusive/unique/ | [reply]
[d/l]
[select] |
|
|
| [reply]
[d/l]
[select] |
|
|
Foo::_method
is printed.
QED | [reply]
[d/l] |
|
|
|
|
|
|
Re^2: Private Methods Meditation
by tilly (Archbishop) on Jul 19, 2004 at 16:04 UTC
|
If you're inheriting from someone else, you're mucking around with their internals.
If you're uncomfortable doing so, then you shouldn't be inheriting. | [reply] |
|
|
tilly, you have a tendency to toss out statements like that without explaining what you mean (that's not intended as criticism.) Are you stating that all OO languages are like this? Clearly you are referring to more than just a blessed referent. With much tighter encapsulation available with Java or C++, do you mean even these languages have the programmer automatically mucking with internals upon subclassing or is this a peculiarity of Perl (or dynamically-typed languages)?
| [reply] |
|
|
I was stating a general rule for all OO languages. There may be additional traps in Perl, but it is true in general.
When I declare a subclass, I'm saying that A isa B. Making this work generally requires that A and B cooperate to some extent. At a minimum, the author of A needs to know what methods B is likely to expect to see overridden. Missing some of them may mean that your object behaves weirdly. Sometimes you need access to class data. In many languages the subclass implementor has access to special protected functions, and needs to know when they are supposed to be called. All of this may need updating if the parent module changes. And so on.
In short, the concept of "isa" represents reasonably tight coupling between components. Some of the tightness is accidental - such as the result of the visibility of the implementation in Perl. But some is intrinsic to what OO is. If you're unwilling to accept this coupling, then you probably shouldn't be subclassing.
Remember that OO provides a series of potential compromises between reducing duplication of information and reducing coupling. It is good to not duplicate information. It is good to have loose coupling. Those goals are good because each avoids a difficult problem. Unfortunately they naturally conflict, reducing duplicate information naturally couples things together.
Among those potential compromises, inheritance is the choice that gives the best opportunity for removing duplication of information. But at a natural cost of tighter coupling.
| [reply] |
|
|
Can't speak for tilly, but it's defaintely something that effects pretty much any language, though Perl might be worse off than most. If you have a method in your subclass, you always run the risk that the parent class will define a method with the same name, but with very different functionality.
I don't remember how the method is searched for in Java, but I believe that if you call that method in the parent, then it calls the parent class's version. This isn't true in Perl without some tricks.
----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.
| [reply] |
|
|
Re^2: Private Methods Meditation
by ihb (Deacon) on Jul 20, 2004 at 00:39 UTC
|
I too am bother with this and I shrug when I see
$self->_private(@args)
because hardly ever has the author documented &_private so I have to be extra careful when extending it and writing my own help routines.
And I really cry when I see
$self->_init(@_);
in the parent class after trying to debug a totally innocent subclass, which happened to have a little help routine called &_init.
IMHO, it's just not particularly clever to call a "private" method as a method since you don't need the method dispatch to find the subroutine, plus you risk being accidently overridden.
Private methods should be invoked as (help) functions, because that's what they are.
_private($self => @args)
is my preferred style.
ihb
| [reply]
[d/l]
[select] |
