Michael G Schwern wrote:
>
> Derived classes will never have to override a base's implementation,
> and all member variables should be private, and everyone will always
> use an accessor, and the UN will bring about world peace, and as long
> as I'm wishing for a perfect world, I'd like a pony. ;)
> I'm still not totally convinced that its so horrid to make the
> File::LockAndKey DESTROY call $self->SUPER::DESTROY manually... but it
> does break encapsulation.
I'm inclined to agree here. I thought about this overnight, and I'm
nervous about it again. It doesn't seem that it's that hard to add a
single line to your SETUP or BLESS or whatever method that calls
SUPER::SETUP.
Remember, for all other methods you'd still have to do this manually. If
you wanted to modify ADD or STORE, for example, just tweaking a few
things, you'd have to manually call SUPER::STORE. I'm not convinced that
this proposal saves enough typing to justify the problems that Michael
mentions.
Plus, what if you want to call a SUPER::'s DESTROY *not* at the start or
end?
sub DESTROY {
my $self = self; # :-)
# do a bunch of stuff here
$self->SUPER::DESTROY(@_);
# do a bunch more stuff here
}
It seems like this RFC enforces stuff that makes subclassing
unnecessarily hard in some cases. At the very least, there should be a
way to turn this off:
sub SETUP : nocascade { }
But then, if you're going to turn it off, why not just leave as-is and
have the person turn it on manually by calling SUPER::? Your other RFC
proposes calling NEXT:: manually, so the same philosophy I think should
apply here.
You could still have hooks for BLESS and REBLESS in bless(), but just
make people manuallly call SUPER::BLESS and SUPER::REBLESS if they want.
People doing Perl OO understand SUPER:: already.
-Nate
