Hi BrowserUk,

You are right in your assumptions. My::XML and My::JSON only provide data to the inherited class, no other methods are used (except methods internally used by My::XML or My::JSON).

If so, if you instantiated an instance of the relevant XML or JSON class to just parse the source data; then retrieved the data required by My class; and then allowed the parse instance to be reclaimed as soon as the initialisation of a new My class instance was complete; then your My class instances might be individually smaller. And possibly more efficien,t because of shorter method resolution paths.

Sorry if I misunderstand your. Are you suggesting the following?:

Package My:

sub new {
   my ($class,%args) = @_;

   my $data;
   if ($args{source} eq 'xml') {
      require My::XML;
      # @ISA = qw/My::XML/;
      $data = My::XML->new(%args);
   } elsif ($args{source} eq 'json') {
      require My::JSON;
      # @ISA = qw/My::JSON/;
      $data = My::JSON->new(%args);
   }

   my $self = bless \%{$data}, $class;
   return ($self);
}
# rest of methods
sub method1 { ... }
sub method2 { ... }

1;
[download]

Package My::XML

package My::XML;

use XML::Simple qw(:strict);

sub new
{
   my ($class,%args) = @_;
   my $self = bless {}, $class;
   $self->_init();
   return $self;
}

sub _init { # Code to read the data from XML source }

1;
[download]

Same for My::JSON

Thank you very much for your comments

Are you suggesting the following?: [ ... CODE ... ]

Yes, that is pretty much what I was suggesting--but only because I assumed that the XML & JSON modules contained classes. Ie. That there was a purpose in inheriting from them because they had local state and more methods than just _init().

With your confirmation that they only contain one _init() subroutine each--although you are calling them as methods--personally, I can see no reason not to simply move the two _init() routines into your My package (with different names), and drop the extra packages.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

With your confirmation that they only contain one _init() subroutine each--although you are calling them as methods--personally, I can see no reason not to simply move the two _init() routines into your My package (with different names), and drop the extra packages.

Well, the main reason is modularity:

• Class My contains methods to deal with a particular kind of data (a kind of trees if that matters) regardless how I feed data to these objects
• My::XML contains, well, code that feeds data coming from a particular source. Although it is true that only _init is used by My, there are other functions/methods that are called by _init (all related with cleaning and parsing the data).
• The same for My::JSON.

For me, it makes a lot of sense to separate code that reads data in a special format to feed the objects from code that manage the objects.

citromatik

Based upon the above assumption, I would suggest that by using inheritance here, you are loading--and persisting--the overheads of the XML or JSON classes into each instance of My class for no good reason. That is, you are forcing each instance of My class to carry around the baggage--instance data and class references--of whichever base class was used to initialise it. And for no good reason, as that baggage will never be used again during the life of the My class instance.

If nothing else, having the initialisation class in the inheritance tree via @ISA, is baggage, if there are no other methods than _init(). Looking back at the OPs code, there seems to be little reason for calling the _init() routines as methods rather than subroutines.

Indeed, as no instance of the initialisation classes is ever instantiated, it could equally be termed "poor OO". And it is a weird use of "inheritance" in every sense. If the idea is simple to provide two methods of initialisation, better I would say to have them both in the main My package space called (say) _initFromXML() and _initFromJSON() and ditch the extra package spaces entirely.

But, as I said, it is quite hard to tell from what the OP posted, as he has obviously simplified the code for the purpose of the question. It is always possible that he also has code in each base package to persist the objects to disk or database, which might make all the difference.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

If nothing else, having the initialisation class in the inheritance tree via @ISA, is baggage, if there are no other methods than _init().

Well, calling two one element arrays "baggage" is stretching the meaning of "baggage". But even so, it's not baggage attached to any instance of the class. Just the classes themselves.

Looking back at the OPs code, there seems to be little reason for calling the _init() routines as methods rather than subroutines.

Hmm, yeah, but that seems to be true of at least 95% of OO code written. I'm not the worlds biggest OO fan, but if I were to do something like the OP, I'd use 3 classes as well, with two classes having just an init method (but with the inheritance tree as showed elsewhere in the thread).

Indeed, as no instance of the initialisation classes is ever instantiated, it could equally be termed "poor OO".

Really? You only use inheritance if you instantiate every class of your inheritance tree? (Or do you write "poor OO" code?)

If the idea is simple to provide two methods of initialisation, better I would say to have them both in the main My package space called (say) _initFromXML() and _initFromJSON() and ditch the extra package spaces entirely.

While certainly possible, it's not something I would do.