i've decided that martin's right and that the named stacks should
follow the usual conventions. i've committed changes so that
EmptyStackException's are thrown and added an isEmpty method. any more
feedback on this new API would be appreciated.
- robert
On 8 Mar 2004, at 03:20, Martin Cooper
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
On Mon, 2004-03-08 at 08:37, robert burrell donkin wrote:
i've committed an implemention plus some documentation.
Do you want this to be in the next release (which is hopefully very
soon)?
Unless you are very confident in the current design, it may be better to
wait until after the release to
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
At 10:23 PM + 2/26/04, robert burrell donkin wrote:
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
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
