Re: Replacing namespaces

This is a very elegant solution to the type of problem you're describing. For those who're confused, what smferris is asking is this:

I have an action I wish to perform on a bunch of data. However, this action is dependent on the type of data I receive. In order to make this as flexible as possible, I'd like to start out in one class (which has a set of actions it can perform), then be able to rebless into another class should that set of actions be insufficient.

I would caution you to do the following:

Make sure that the reblessings are in a known tree. In other words, if A doesn't work on X, it will always go to B, not C. If A doesn't work on Y, it goes to C, not B. Make sure that this set of transformations is well-documented.
Make sure that the set of transformations document above will cover all your possible needs.
Supply a default error case, which fails out with a useful error message.
Supply a way to follow the reblessings using some method of logging, even if it's only prints to the screen. Even after debugging the first iteration, leave the debugging in, just in case.
Make sure that all the classes use the same data structure hierarchy. In fact, I would build a base class, which supplies the attributes, and have the other classes supply the actions. The base class should have all the actions as virtual methods. (For more info, use Super Search or read Perl OO by Damian Conway.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on Re: Replacing namespaces

Replies are listed 'Best First'.

Re(2): Replacing namespaces
by dmmiller2k (Chaplain) on Dec 11, 2001 at 20:09 UTC

I concur; this is a very elegant solution, kind of like a dynamic dispatcher.

Expanding upon the concept of making sure the reblessings are in a known tree, what you are describing appears to be a Finite State Machine.

Given a current state (class A) and event (X fails), a new state (class B) is chosen; or, alternatively for a different event (Y fails), a different new state (class C) is selected.

Construct a table with all possible states down the Y-axis and events across the X-axis, thus documenting the permitted state transitions. Here a dash (-) represents illegal states (i.e., should not happen, is an error if it does):

state  |  event X  |  event Y  |  event Z
-------+-----------+-----------+-----------
  A    |     B     |    C      |    E
-------+-----------+-----------+-----------
  B    |     D     |    -      |    E
-------+-----------+-----------+-----------
  C    |     E     |    -      |    -
-------+-----------+-----------+-----------
       |           |           |

... etc.

       |           |           |
-------+-----------+-----------+-----------
  E    |     -     |     -     |    B
-------+-----------+-----------+-----------
[download]

There are probably other ways to track a complex transition graph, but I've gotten great use out of this qapproach.

dmm

You can give a man a fish and feed him for a day ...
Or, you can teach him to fish and feed him for a lifetime

[reply]
[d/l]


Welcome to the Monastery
	PerlMonks