Re: OO Inheritence

[chromatic]

in reply to OO Inheritence

use base Vehicle;
@ISA = 'Vehicle';

Pick one or the other, not both. I prefer base.

croak "$option is not valid" if ! $self->_valid( $option );

Use unless.

my %valid = map { $_ => 1 } qw( Wheels Doors Color Passengers );
my %ro    = map { $_ => 1 } qw( Wheels );

sub _read_only {
    my ($self, $option) = @_;
    return defined $ro{$option} ? 1 : 0;
}

If you elided the lexicals in favor of class methods, you wouldn't have to repeat this code in both subclasses:

sub _attributes
{
    return
    {
        map { $_ => 1 } qw( Wheels Doors Color Passengers )
    };
}

sub _valid
{
    my ($self, $attribute) = @_;
    return exists $self->_attributes()->{ $attribute };
}

Finally, aside from inheriting a constructor and an AUTOLOAD, I don't see any reason why you need to inherit here. You'd probably be better off using a module that autogenerated your accessors. It's not wrong, but I don't see any real benefits to this approach.

I did it this way when I was first learning, though. It won't cause you any real trouble; it's just a bit more complication that doesn't add very much. ~shrug~

[exussum0]

Croaking in your constructor is a bit harsh. How about undef? As chromatic said, if you dont' read documentation about something, like this, you get what you deserve. I don't agree with that, because if someone carelessly creates something great that ignores croak, and then you use that, you may find yourself with a bug 'cause of some odd situation.

At least w/ undef, you can be more forgiving.

[stvn]

At least w/ undef, you can be more forgiving.

But it also requires that it be checked for. I think returning undef has its place, but so does throwing an exception (a.k.a. - croaking). I see the logic in allowing the user of your object/class/module to choose to die or not, after all, this...

my $o = Class->new(@arg) || die "cannot create new Class";

is a common enough idiom. But I can also see the logic in throwing an exception and just requiring the user to catch that exception. For me, it really comes down to how you plan to structure the error handling in the rest of your code.

[tilly]

And you never mistype a parameter name?

When I've done something wrong, I like informative error messages. Think of error checks like that as being kind of like strict.pm in effect. It saves me time in development. That someone who shoots themselves in the foot deliberately won't see the benefit is not a problem for me.