in reply to class inheritance and new(constructor)

There's a possible problem with this sort of thing that you might want to think about: in perl, only the first "new" found in a chain of inheritence is going to be called.

Damien Conway presents a system where initialization is broken out into "_init" subs, and the "new" is inherited from a "mixin" class. The idea there is that the child _init's can explicitly call the "_inits" of the parent class.

See the book "Object Oriented Perl" (published by Manning), Chapter 6 "Inheritanced", listing 6.1 on page 174.

  • Comment on Re: class inheritance and new(constructor)

Replies are listed 'Best First'.
Re^2: class inheritance and new(constructor)
by aufflick (Deacon) on Jul 17, 2006 at 01:05 UTC
    I like to use a simplified version of this (excellent) concept. I try to have only one simpele new method in the base class (and my apps try to have only one base class a la Objective-C/Java etc.) which calls an _init method for the initialisation tasks. It seems to work fairly well for me. Eg:

    package MyApp::BaseClass; sub new { my $class = shift; my $init_args = shift; # a real example would have warnings etc. here. ref $init_args eq 'HASH' || $init_args = {}; my $self = { _init => $init_args }; bless $self, $type; # self is re-assigned to allow the _init to replace itself $self = $self->_init() || UsefullErrorObject->new({ class => $class, args => $i +nit_args }); return $self; } sub _init { my $self = shift; # subclass this # first hashref argument to new() is in $self->{_init} return $self; }
    A real benefit of this setup is that since you never sublass new() you can always guarantee that new() will return an object (possibly an error object) which removes the need to test every object creation with an if defined type test.

    Season to suit.