> Janus Dam Nielsen <[EMAIL PROTECTED]> writes: > > I de-top-posted your mail, see below. > >>> One would probably represent the expression tree explicitly and >>> evaluate it starting with the leaf nodes. >>> >>> If all nodes are associated with a program counter (as in VIFF), >>> then >>> that could be used as a key to lookup the right node to evaluate >>> when >>> data arrives from the network. If a add-node has both inputs ready, >>> then it is removed and its parent then has one less input to wait >>> for. Yeah, that could definitely be programmed... :-) >>> >>> Using a thread to receive listed for input, and another thread to >>> work on reducing the tree, then this should work nicely. Perhaps a >>> third thread to send out messages produced by the tree reducer... > >> After some more thought, then I just consider this an instance of the >> observer visitor. Maybe with some threads if you want some stuff done >> i parallel. > > Do you mean both the observer and the visitor pattern?
> > I see what you mean about the observer pattern since each variable in > the program is observed by the operations that depend on it. So > > x = add(a, b) > y = mul(a, b) > z = add(x, y) > > would create an add operation that observes the a and b variables > and a > mul operation that does the same. Finally, an add operation would > observe x and y and notify z. > > When a and b get a value (from incoming network traffic) they notify > their listeners. The add and mul operations could then proceed by > having > x, respectively y, notify their listeners which would be the add > operation defining z in this example. > > Such a structure is also quite nice! > Yes I mean exactly that, and that is what you use -- Janus Den 07/12/2007 kl. 14.34 skrev Martin Geisler: > Janus Dam Nielsen <[EMAIL PROTECTED]> writes: > > I de-top-posted your mail, see below. > >>> One would probably represent the expression tree explicitly and >>> evaluate it starting with the leaf nodes. >>> >>> If all nodes are associated with a program counter (as in VIFF), >>> then >>> that could be used as a key to lookup the right node to evaluate >>> when >>> data arrives from the network. If a add-node has both inputs ready, >>> then it is removed and its parent then has one less input to wait >>> for. Yeah, that could definitely be programmed... :-) >>> >>> Using a thread to receive listed for input, and another thread to >>> work on reducing the tree, then this should work nicely. Perhaps a >>> third thread to send out messages produced by the tree reducer... > >> After some more thought, then I just consider this an instance of the >> observer visitor. Maybe with some threads if you want some stuff done >> i parallel. > > Do you mean both the observer and the visitor pattern? Yes. > > I see what you mean about the observer pattern since each variable in > the program is observed by the operations that depend on it. So > > x = add(a, b) > y = mul(a, b) > z = add(x, y) > > would create an add operation that observes the a and b variables > and a > mul operation that does the same. Finally, an add operation would > observe x and y and notify z. > > When a and b get a value (from incoming network traffic) they notify > their listeners. The add and mul operations could then proceed by > having > x, respectively y, notify their listeners which would be the add > operation defining z in this example. > > Such a structure is also quite nice! Yes it is! (good description) The mental concept which you use callbacks to implement is exactly an observer relationship. In java you don't have the possiblity to use functions as values so you backage them in objects and then call the functions in the objects instead. And you can use threads and networking and RMI or what ever as in Python. You would have to declare some common type like Share or ObservableShare or something which declares the method which should be called when an event occurs. This is in essence quite similar to the example you wrote initially. > -- > Martin Geisler _______________________________________________ viff-devel mailing list (http://viff.dk/) [email protected] http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
