Hi All. I've been thinking about it, (and about Omer's proposal. Oh, and of course the code is in Perl) and maybe I don't need to change the design so much. Maybe I just need to change calls like: $child->_action($data, ...) to: $parser->_action($child, $data, ...);
where $parser is an object that accompany transversing the object tree, and it will call to $child->_action(...). That will give me one point to put my hooks in, and will be easy to implement. Price: double stack depth, and I'll have to implement some getters / setters in $parser, for the objects to manipulate. However, I quite liked the idea of having an iterator transverse the object tree. it seen... elegant. but maybe it's not the right thing to do here. Comments? Shmuel. 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? > _______________________________________________ > Perl mailing list > [email protected] > http://perl.org.il/mailman/listinfo/perl > _______________________________________________ Perl mailing list [email protected] http://perl.org.il/mailman/listinfo/perl
