> On 29 Sep 2015, at 21:24, Peter Levart <peter.lev...@gmail.com> wrote: >> Just a few *more* bike sheds to paint :-) I am concerned i will never finish >> this nor other un/related tasks. >> >> For now I am ok with Objects being that "argument checker class” simply >> because it already has a gravitational pull due to the mass of the existing >> check methods [*]. >> >> Paul. >> >> [*] I believe it is a backwards compatible to change Objects to extends from >> Preconditions and move the existing static check methods to Preconditions. >> That seems like a sleazy trick though. > > Yes, but the same could be achieved by just re-implementing those 3 methods > in Preconditions or delegating from Preconditions to Objects - without > strange subtyping. >
I know :-) > I think it's worth introducing Preconditions class. checkNotNull overloads > are equally well suited for Objects as they are for Preconditions, so it's > not wrong to have them in both, while checkIndex and friends don't really > suit any of the existing classes. If I would have to search for them in among > existing classes, Arrays would be the place to look first. List interface the > 2nd. IndexOutOfBoundsException wouldn't come to my mind, as Exception(s) are > usually not homes for logic, neither would Integer which is to abstract to > mentally associate it with array or list index checks. > The concern i have is once Preconditions is let loose the scope expands with proposals for “just one more method” (there is even the opportunity to bike shed over the names checkNotNull or requiresNotNull etc. etc.) I don’t want to discuss such additional methods right now otherwise i will never make progress with the current set. A way forward is to initially include Preconditions with *only* the check index methods, and in subsequent proposals selectively add more. At the moment i am still leaning towards Objects. Paul.
