Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

On Sat, Sep 02, 2000 at 11:05:23AM +1100, Damian Conway wrote:
>    > This bothers me.  It leaves no way to override the behavior of a
>    > parent's SETUP and DESTROY, you can only overlay.  You mentioned that
>    > this is normal for most other OO languages, so I presume there's a way
>    > to deal with this?
> 
> The issue never arises. It's always assumed that as a client of the base
> class a derived class has no business medding in the base's implementation.

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 don't buy it.  Not in Perl.  Why should DESTROY and SETUP be any
different than any other method as far as wanting to override features
goes?  Your logic suggests that I'd never want to meddle in the base's
implementation. 

I can most certainly think of cases where a base class's DESTROY does
something a derived class doesn't like.  Consider your example,
File::Lock.  File::Lock::DESTROY calls flock($fh, LOCK_UN).  I derive
File::Lock::Mac from File::Lock.  Uh oh, Macs don't implement flock!
Under your proposal, I'm screwed.

Of course, File::Lock should have realized that flock() is nonportable
and had DESTROY call a my_flock() method which File::Lock::Mac could
override.  But not everyone thinks that far ahead, and I'm not about
to buy a saddle for that pony just yet.


>    > Also, having never really desired hierarchical DESTROYs, its not
>    > obvious to me why this is useful.  Could you explain why? (and for the
>    > benefit of those who don't own OO Perl or made the mistake of loaning
>    > it out.)
> 
> Suppose you inherit from a class with a non-trivial destructor.
> Say, File::Lock, whose destructor releases a lock on a file when
> the object goes out of scope. Now you create a File::LockAndKey,
> which requires a special File::Key object to acquire the lock.
> When the File::LockAndKey object goes out of scope, the File::Key object
> has to be informed, so you need File::LockAndKey::DESTROY to do that.
> As soon as you provide that method, File::Lock::DESTROY ceases to be
> called and your files never unlock. :-(

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.

If you can figure a way out of the dilema I proposed above, I suppose
this makes sense.


> You must have missed RFC 187, which covers that. I've proposed that
> the second argument to bless *automatically* apply C<ref $proto ||
> $proto> :-)

I read #187 afterwards and got it.


-- 

Michael G Schwern      http://www.pobox.com/~schwern/      [email protected]
Just Another Stupid Consultant                      Perl6 Kwalitee Ashuranse
Cheating is often more efficient.
        - Seven of Nine