On Wed, Mar 19, 2008 at 9:28 AM, Adam Lally (JIRA) <[email protected]> wrote: > Users sometimes need to implement the Java iterator interface, in which case > they need to make sure that their hasNext method doesn't advance the iterator > - so I don't see that this is that different. I guess a difference in UIMA's > case is that there's another level of indirection (the CasIterator) between > the calling code and the CasMultiplier, so we could afford to have different > contracts at the two layers. CasIterator's hasNext could be called any number > of times, but the CasMultiplier's would be guaranteed to only get called > once. I think that's what your fix is doing. So since end users never > interact with the CasMultiplier interface directly, it's not a huge loss if > it's contract doesn't follow the standard iterator paradigm. > > I guess I still have a preference for keeping the contract with the > CasMultiplier analogous to the normal Iterator contract, since I think most > people think that an interface with hasNext/next operates in this way. And > who knows, maybe someone else has written some code that directly calls a > CasMultiplier component outside of the UIMA framework, and they'd be tripped > up by this. Unlikely, but possible. > > Does anyone else want to voice an opinion?
The documentation claiming that the work in CAS multipliers can be distributed between hasNext and next is currently insufficient. Either it should be changed to warn users to protect their hasNext code from being called multiple times, or the UIMA code changed to avoid hasNext being called unnecessarily. I'd vote for changing the code instead of the documentation. User code that directly calls a CasMultiplier component outside of the UIMA framework should get exactly what it asks for. Eddie
