Re^4: Modification of @ISA at run time

When ->isa checks are used with respect to the delegate for the prupose of type checking (what kind of archive format do you encapsulate, mr Archive::Any instance?), then it's perhaps a design problem, because not caring is the reason we wrapped it in the first place.

But one may find desirable to have some common functionality plus extra type-specific features, e.g.

if ($this->isa 'cool_archive') {
    print $this->name, " is a cool archive.\n", <<EOT;
You also have the following cool features:
... (more cool features)
EOT
    # interactively ask user to pick one...  
}
[download]

Or is such a design to be considered inherently risky?

Comment on Re^4: Modification of @ISA at run time Download Code

Replies are listed 'Best First'.
Re^5: Modification of @ISA at run time by nothingmuch (Priest) on Sep 01, 2005 at 15:36 UTC
This example is not well suited for a delegator model, but for a factory one, where each class presents it's routines to the routine displayer code (polymorphically, too - the code that has these archive plugins shouldn't care, it should only handle the interactivity). The open archive command takes a CLI, and dispatches to a factory constructor, that chooses the right class, and then the instance of this class is presented to the user with the enumerated options, extracted metadata, and so forth. -nuffin zz zZ Z Z #!perl	[reply]
Re^6: Modification of @ISA at run time by blazar (Canon) on Sep 01, 2005 at 15:46 UTC
TY again for the clarification. I understand what you mean. OTOH your own article at Re: Modification of @ISA at run time stresses the advantages of the delegator model over the class factory one when one has to deal with many methods needing different "versions" each depending on some conditions. So the question is: what if one has both requirements? I.e. the latter one on a set of "common" methods (exposing a uniform interface) and the need for type-specific features as well?	[reply]
Re^7: Modification of @ISA at run time by nothingmuch (Priest) on Sep 03, 2005 at 13:12 UTC
I have not yet met such a case... I think the two are fundamentally contradicting - one is trying to blur the difference, and the other is trying to make it obvious. The issue is that object which have type specific features are not really polymoprhic WRT to each other, but only WRT to their superclass. Any code that deals with such a case should probably either try to deal with smaller chunks of functionality, talk to the delegates directly, or make the program work a bit harder by making a better factory. -nuffin zz zZ Z Z #!perl	[reply]