<snip/>
> I can definitely understand your thinking but it is a feature I thought was
> quiet handy too. In the example of DateValidator, checking the string is a
> valid date involves the creation of a Date object and it seems silly to
> throw that instance away when we're only going to recreate it later. If you
> really don't like the idea of modifying the list parameter I suppose we
> could change the sig to List validate(List) (Although you should be aware
> that at least DefaultOption's process() method modifies it's ListIterator).
Maybe calling it a Validator is incorrect then. I had thought
of changing the method to return a List but then it is no longer
a validation method, it is a validation and conversion method.
We could modify the signature as follows:
void validate(Option, List)
The new values can be set on the Option rather than modifying
the list.
Or we could define a new interface that extends Validator
with one method that returns a List (the object instances).
So validators can implement Validator and validators/convertors
can implement this new interface (not sure what name to give it).
To avoid throwing away the newly created objects we could cache
the results in the validate method and return them via the
new method.
I've started to ramble now so I should stop ;)
-John K
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
