Interesting OO/package conundrum...

dragonchild has asked for the wisdom of the Perl Monks concerning the following question:

I've got the following situation:

I have a number of classes that all inherit from some base class. Let's call them Foo and Bar inheriting from Base.
Now, I have a bunch of class information, such as Required attributes, that every class inheriting from Base will be setting up. The function to see if a given attribute is required or not is the same for all children, hence I want to put it in the Base class.
It used to be that this class information was stored in every instance of this class. As there's a ton of this information and I might be instantiating 1000+ objects of a given class, it makes sense to put this at the package level.

The problem I'm having is that the function in Base can't access the information in the package of Foo or Bar.

So, I'm thinking about this and I came up with a number of possible solutions.

Have the function in Base use soft references. Ugh!

sub isRequired {
    my $self = shift;
    my $attr = shift;

    my $class = ref($self) or croak "No class name!\n";

    no strict 'refs';
    return (${"$class::Required"}{$attr});
}
[download]

Have each object have an attribute called 'Required' and have that contain a reference to the package-scoped variable. This cuts down on the duplicated information, but it still feels like I'm having to kludge. The function would now look like
```
sub isRequired {
    my $self = shift;
    my $attr = shift;

    return ($self->{Required}{$attr});
}
[download]
```

I guess what I'm bitching about is that even though $self is from package Foo or Bar, blah() is executing within the namespace of Base. Is there some way I can get around this? Is there another solution I'm not seeing?

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on Interesting OO/package conundrum... Select or Download Code

Replies are listed 'Best First'.
(tye)Re: Interesting OO/package conundrum... by tye (Sage) on Oct 12, 2001 at 01:02 UTC
You can use a method: `package Foo; my %Required; BEGIN { @Required{qw(This That TheOther)}= (1)x3; } sub _GetRequired { return \%Required; } # ... package Base; sub _GetRequired { return {}; } sub isRequired { my $self = shift; my $attr = shift; return $self->_GetRequired()->{$attr}; }` [download] (Updated.) - tye (but my friends call me "Tye")	[reply] [d/l]
Re: Interesting OO/package conundrum... by premchai21 (Curate) on Oct 11, 2001 at 23:15 UTC
The second is the standard solution. The first is more kludgy IMHO. The second is what is recommended in the perldocs (perltoot IIRC).	[reply]
Re: Interesting OO/package conundrum... by runrig (Abbot) on Oct 12, 2001 at 01:12 UTC
Is there some way I can get around this? Get around what? Seems like the best solution to me. One method in the base class which accesses data from the inheriting class.	[reply]
(jeffa) Re: Interesting OO/package conundrum... by jeffa (Bishop) on Oct 12, 2001 at 01:12 UTC
i don't have an answer, but i thought you should check out a similar question over at JavaJunkies: An intriguing question about Inheritance. In the meantime, i'll be looking into/studying reflection myself :) jeffa inheritance is a one-way street	[reply]
best example (re:Interesting OO/package conundrum...) by t'mo (Pilgrim) on Oct 12, 2001 at 17:37 UTC
Good that you referred us to that thread. This example was the best. To answer the original question, a solution in Perl might (with a disclaimer) look something like this: # NOTE: untested pseudo-code below! package Base; sub new { ... $self->{'requiredValue'} = getRequiredValue(); ... } # ensure that my child classes do things properly sub getRequiredValue { die "Subclasses must implement 'getRequiredValu +e'" } ... package Child1; sub getRequiredValue { 42 } # you know it's the answer :-) ... package Child2; sub getRequiredValue { 360 } ... package main; my ($c1, $c2); $c1 = Child1->new(); # Call trace looks like: # 1. Base::new # 2. Child1::getRequiredValue $c2 = Child2->new(); # This call trace is different: # 1. Base::new # 2. Child2::getRequiredValue !!! [download]	[reply] [d/l]
Re: Interesting OO/package conundrum... by pike (Monk) on Oct 12, 2001 at 15:13 UTC
You could also use a class attribute on Base, rather than an instance attribute: `package Base; my %_required = ('Foo' => {one =>1, two => 1, three =>1}, 'Bar' => {one =>1, three => 1, fourteen =>1}); sub isRequired { my ($self, $attr) = @_; my $class = ref $self; return exists $_required{$class}->{$attr}; }` [download] This way, you will store the hash of the required attributes only once. Greetings, pike	[reply] [d/l]
Re: Re: Interesting OO/package conundrum... by dragonchild (Archbishop) on Oct 12, 2001 at 16:49 UTC
This is an interesting idea, and one I thought about. But, I rejected it because this would require that the base class knows about the child classes, even if it's only the names. A goal for OO is that no-one knows anything more than they absolutely have to. Have a class know something about its children is, generally, a no-no. shrugs ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.	[reply]
Retitle this thread: cannot access class data of derived classes in parent method by princepawn (Parson) on Oct 12, 2001 at 19:58 UTC
I think this title is really what you are saying. PRINCE "jobless business object layer designer" PAWN	[reply]