- robert
On 28 Feb 2004, at 20:06, Martin Cooper wrote:
I can't think of a specific use case for named stacks, but I'm prepared to
believe that one exists. I certainly appreciate the need for communicating
between rules, since that's something I've needed before, and I guess I
could use named stacks for that, once it's in place.
A couple of specific comments:
* I don't see a need to auto-create the stack on get-style operations (e.g. pop and peek). I would think it would be sufficient to create it only when something is being pushed on to it.
* Wouldn't you want to throw an exception if someone tries to pop a value
off an empty or non-existent stack? You didn't specify the behaviour
below, but I'm assuming that you're currently planning on returning null
in those circumstances?
-- Martin Cooper
On Thu, 26 Feb 2004, robert burrell donkin wrote:
i've talked about this before but i think that i'll probably now have time to implement this (once the design's settled, of course ;).
it'll probably be easiest for me to outline the proposed interface face
first and then follow it with some explanation.
/** * Pops an object from the named stack. * If the stack does not exist, it will be created. * @param stackName the name of the Stack from which an object should be popped */ public Object pop(String stackName);
/**
* Pushes an object onto the named stack.
* If the stack does not exist, it will be created.
* @param stackName the name of the Stack onto which the object should
be popped
* @param object the Object to be pushed onto the named stack
*/
public void push(String stackName, Object object);
/** * Peeks at the Object on the top of the named stack/ * If the stack does not exist, it will be created. * @param stackName the name of the Stack to be examined. */ public Object peek(String stackName);
named stacks are intended to help solve the problem of inter-rule
communication in a general and flexible way. at the moment, digester
uses two stack for communication: one for the principle objects and one
for parameters but no other forms of communication are provided for.
named stacks is about providing an unlimited supply of extra stacks for
use by rules. two rules can communicate by pushing and popping the
stack with the same name.
a simple hashmap (allowing named objects) has been proposed as a solution to the problem of communication. i feel that named stacks provide all the functionality that a named object would provide (one rule pushes an object onto a particular stack, the other peeks at it) but also allows more complex communication helpful when processing deeply nested tags. (in this case, one rule might push several objects onto a particular stack and then a later rule may pop them off in order. of course, you could achieve the same effect by putting a list into a hashmap but i think i prefer the conceptual purity of stacks.)
i might be persuaded that the signatures should be objects rather than strings (i feel that named stacks has better conceptual strength than indexed stacks).
comments welcomed :)
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
