Re^5: Modification of @ISA at run time

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

Comment on Re^5: Modification of @ISA at run time

Replies are listed 'Best First'.
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]