Re: Conditional inheritance strategy

[BrowserUk]

Hm. It's not possible to tell from the posted snippets whether this really makes sense.

My instinct tells me that the XML or JSON is only used to initialise the objects of class My, and that once so initialised, the instances from either source are essentially identical. If so, then I would deem what you are doing as "unnecessary inheritance".

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 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.

Hard to tell from what you've posted, but worth considering.

[citromatik]

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;

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;

Same for My::JSON

Thank you very much for your comments

[BrowserUk]

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.

[citromatik]

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.

[JavaFan]

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.

I wonder what baggage you are referring to. I would presume to point of _init is to set up instance data - why else call a method named _init from new? Of course, if said data is never used, it's pointless, but the code fragment doesn't suggest so. As for a class reference, any object will have a class reference - a single string (package name). The reference doesn't increase depending whether inheritance is used or not. But even if I misunderstood you, your arguments seem to be against using inheritance in general, and not specific to the OP.

[BrowserUk]

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.

[JavaFan]

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.