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

   > > Furthermore, it proposes that both C<SETUP> and C<DESTROY> methods
   > > should be invoked hierarchically in all base classes.
   > 
   > 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.


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

   > PS  Proposing SETUP, UNIVERSAL::new() and the hierarchical calls are
   > three unrelated issues and should probably be three different RFCs.

I felt they were all inextricably linked. See below.


   > >         package UNIVERSAL;
   > >         
   > >         sub new { bless {}, @_ }
   > 
   > Shouldn't that be:
   > 
   >     sub new {
   >         my($proto) = shift;
   >         my($class) = ref $proto || $proto;
   > 
   >         bless {}, $class;
   >     }
   > 
   > I prefer new() to be both an object and a class method 

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


   > Also, do we want to do anything with the rest of the arguments?

Err, I already was.

	bless {}, @_;

is:

	bless {}, $_[0], @_[1..$#_];

which passes the remaining ctor arguments directly to your C<SETUP> method.
Neat, huh? :-)

(That's why the C<SETUP> and default C<new> are in the same RFC. Obviously 
I didn't make the connection clear enough in the RFC. I'll remedy that.)


Damian