Config::General inheritance [SOLVED]

[fbicknel]

Greets

I'm trying to write a module that inherits from Config::General. The way C::G works, you need to say 'ExtendedAccess => 1' in the ->new, and what you get back is an object of class Config::General::Extended.

All well and good, but as soon as I bless the returned object into my new class, $self->isa ("Config::General") still returns 1, but $self->isa ("Config::General::Extended") now returns false.

This causes any AUTOLOAD calls to fail and any attempts to get to methods in ::Extended fail. (Turns out AUTOLOAD is in Extended, so these two things make sense together.)

Anyone know what in Config::General or C::G::Extended might cause such a "drop" of inheritance?

[Corion]

Do you inherit from Config::General::Extended? Otherwise, you won't get access to its methods...

[GrandFather]

How about you show us some sample code?

[fbicknel]

Well, I just stumbled into it.

I was a bit blinded by this ExtendedAccess parameter doo-dad. I just discovered that if I:

use base qw (Config::General::Extended);

yet still call new on Config::General, I get the desired result.

Corion was trying to tell me that; and when I finally paid attention, it was obvious.

Thanks for reading along... :)

[fbicknel]

Well now. I even have replicated how I wound up going down that primrose path. When I went back to my production code, I found in my inheriting module; after applying the revelation I talked out in this forum:

use base qw (Config::General::Extended);
sub new {
...
  my $self = new SUPER::new (
...

Which of course executes C::G::Extended->new... and that's a bad thing.

Instead of changing SUPER to Config::General, as I should have, I changed the use base line. Ah. So that's what happened.

[fbicknel]

Good points, Corion & Grandfather. I'll try to oblige: First, the way Config::General insists on doing business, you include C::G and tell it you want to use the Extended module through the ExtendedAccess parameter (see code). Looking at the code, it does indeed pull in that module like this:

 189   if ($self->{ExtendedAccess}) {
 190     # we are blessing here again, to get into the ::Extended name
+space
 191     # for inheriting the methods available overthere, which we do
+esn't have.
 192     bless $self, 'Config::General::Extended';
 193     eval {
 194       require Config::General::Extended;
 195     };

(This appears in Config::General)
This funkiness may indeed be the source of my frustration... it doesn't look like a traditional inheritance is set up here, despite it saying so in the comment. :) Am I right?
Ok, so now a sample piece of code. First the code:
Read more... (3 kB)
And then the output when you run this (perl 5.8.8, Config::General v2.42)
Read more... (1333 Bytes)

[Arunbear]

Effective Java has some good advice: Favor composition over inheritance

Having to write your own new method is a sign that Config::General wasn't designed for you to subclass it (although you managed to do it with a constructor hack)

[fbicknel]

Thanks for the suggestion: I read the item. But it's unclear whether composition is warranted in this case. I could probably get by without overlaying ->new, and in fact my modifications are small. The main reason I decided to use inheritance was to ease the implementation of Config::General over my own Local::Config. It turns out that most of my existing Config was a subset of Config::General's behavior, so I figured that by adding in a subclass those bits that weren't implemented, I could satisfy all the legacy code's Local::Config features and then start writing new code that capitalized on Config::General's features as well.

I have to admit your suggestion gives me pause, however. I'll give it another look before finalizing anything and will keep these points in mind as I work further on it.

Thanks!