commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ola Berg" <ola.b...@ports.se>
Subject Re: [Lang] Validate
Date Wed, 23 Oct 2002 10:00:13 GMT
From: <scolebourne@btopenworld.com>

> Are you volunteering to write this ;=) ??

Sure. Since

1) This has a very broad user base w/ lots of opinions and
2) I don't like to code in vain

...I'd just like an agreement on the initial public interface before I proceed.

> Do we :
> 1) only deal with IAEs

Validate is IMO implicitely dealing with arguments in an object's methods. State applies to
the object as a whole. Such validation is more like validating a correct argument in the wrong
time. I cannot see how one can validate state at the target object in a generic manner. 

If it is a matter of validating the state of the object you pass as an argument, I would say
that an illegal state in that object makes that object an illegal argument. ISE should be
thrown if a method call brings the _target object_ into an illegal state.

Or?

> 2) put IAEs and IStateE (ISEs) in the same class, thus prefixing each method by argument
and stateCheck

Ugh, no. But see below, there might be room for them existing in the same class.

> 3) Name the classes ValidateArgument and ValidateState.

If there are possible generic utility methods for checking state, _perhaps_ a utility class
containing them should be called "ValidateState" (the exact name of the class depends a bit
on the proposed name of the methods, the whole method call must feel natural).

"Validate" validates the arguments of its method. I favor "Validate", and leave the ValidateState
for now. But if anyone has a suggestion for the interface of the similar state validating
utility, speak up now so that I can write (and name) them in parallel. The easiest way of
avoiding future clashes: think beforehand.

If there are reasonable utility methods for checking state, I suspect that their naming patterns
would be so much different than the names for the argument checking methods, so that they
could live happily in a single Validate class.

> For your interface, I would name the type method isInstanceOf, instead of isOfType.

Hmm, yes, semantics would be that of the instanceof operator. I agree on that.

> Yes, to basic String and Collection methods. No, to the number ones (isTrue(i > 0)
is just as easy).

Agree. What about the wrapper classes (Integer etc)? 

The fact is that isTrue() _is_ easy for anything, so that apart from the array checking methods
and the null check, anything could be easily done with isTrue(). For the object checking,
you would only be missing the implicit notNull() check (which is a compelling reason to keep
those methods).

> Yes, to having two versions of each method, one with a message and one without. The one
without could create a sensible error message.

Agree.

/O


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


Mime
View raw message