> > 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
