commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [digester][PROPOSAL] named stacks
Date Sun, 07 Mar 2004 19:37:26 GMT
i've committed an implemention plus some documentation.

- 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message