"this approach discourages messing about with class hierarchies at run time, by reassigning @ISA. The temptation to modify @ISA at run time is usually a sign that your class might be better implemented as a factory, a façade, or with some other meta-object technique. (Emphasis added.)
Atypically, Damian doesn't provide an example of the code that would implement one of those other techniques. Not being experienced in design patterns, I'm somewhat at sea here. So I'm wondering if someone could provide a simple example of, say, the alternative to something like this:
BEGIN { use vars qw ( $VERSION @ISA ); $VERSION = '0.01'; require Solar::Data; require Lunar::Data; push @ISA, qw( Solar::Data Lunar::Data ); };
And later, at run time ...
if ($sun_rises_in_west) { require Astrological::Data; unshift @ISA, Astrological::Data; }
... called because, under certain unusual conditions, I want to make sure that the inheritance mechanism finds an Astrological::Data method (say, get_sunrise_time) before it finds Solar::Data::get_sunrise_time().
What would the alternative approach look like in code? Why, particularly in a simple case, would it be superior?
Thank you very much.
Jim Keenan
In reply to Modification of @ISA at run time by jkeenan1
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |