[Israel.pm] Design Question

Omer Zak w1 at zak.co.il
Wed Nov 19 13:02:12 PST 2008


NOTE:
Even though the application is probably in Perl, I am discussing the
design as if the language is C.  Make your adaptations to Perl as
needed.

Have the client pass to "base", as an additional argument, callback as
follows.  When a node calls its children, it also passes callbacks to
its children.
The callbacks will have the following signature:

  Callback *aCallback(Mode mode, NodeType nodetype, Node *node);

Where:

  mode is either BEFORE_CHILDREN, AFTER_CHILDREN or LEAF.
  nodetype is the calling node type.
  node is pointer to the current node.

When a node is visited, if it is leaf it calls the callback once with
the LEAF mode.
If it is not a leaf, it calls twice the callback - once before
traversing its children, once afterwards.

The callback is supposed to return a function pointer to a callback -
either the same function or another function (including NULL).  This
function pointer is passed to the children nodes, and they invoke it as
the callback.  This mechanism is intended to allow you to fine-tune
debug messages printing and other actions according to node type,
nesting depth, etc.
                                  --- Omer


On Wed, 2008-11-19 at 22:39 +0200, Shmuel Fomberg wrote:
> Hi.
> 
> More details for my question:
> The "action" gets a tree as input, that corresponds the object tree, and 
> each node in the object tree have equivalent in the input tree.
> Some of the nodes need to pre-process the input tree for their children, 
> or post-process the result.
> 
> So, any advice?
> Shmuel.
> 
> Shmuel Fomberg wrote:
> > I need a design advice on my module, Data::ParseBinary.
> > 
> > The module works in the Composite design pattern, which means that all 
> > the classes inherent from one base class "base", and each object may 
> > have zero or more "children".
> > The base class defines two methods, build and destroy, and each 
> > sub-class must implement them, optionally calling the same method in 
> > it's children, if exists and if it decides to.
> > 
> > The current operation is pretty naive, that the program calls the root 
> > object, and it calls it's children's methods and so on.
> > 
> > The problem is that this design is not flexible. what if I want to print 
> > a debug message before and after every object in the hierarchy? What if 
> > I want to also print what each action returned?
> > 
> > After a talk with Shlomo, I'm thinking about modifying the system to 
> > iterator-style, where the iterator will traverse the object tree, and 
> > each object will queue it's children in the iterator.
> > 
> > What do you think? How would you do it?
-- 
"Kosher" Cellphones (cellphones with blocked SMS, video and Internet)
are menace to the deaf.  They must be outlawed!
(See also: http://www.zak.co.il/tddpirate/2006/04/21/the-grave-danger-to-the-deaf-from-kosher-cellphones/)
My own blog is at http://www.zak.co.il/tddpirate/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS:  at http://www.zak.co.il/spamwarning.html




More information about the Perl mailing list