Include other design-by-contract constructs

[GoogleCodeExporter]

Class Preconditions is a good start for allowing users to add library-based
Design by Contract constructs to their code.  This should be expanded by
offering other classes, for example, Invariant and Postconditions.  Move
some methods from Preconditions (like checkState() to Invariant) and add
other methods (like checkReturn() to Postconditions).

Perhaps a new package, com.google.common.dbc, is in order?

Also, I would like to see better integration with Predicates.  Basically,
for every method like:

checkArgument(boolean b)

there should be a method like:

checkArgument(Predicate<T> p, T object)

This would allow clients of Preconditions to express their conditions more
compactly.

Original issue reported on code.google.com by russ.mil...@gmail.com on 25 Mar 2009 at 3:18

[GoogleCodeExporter]

We're working on this.  Making the right API decisions to satisfy everyone is
extremely difficult.  The current, as of yesterday, notion is:

* For any check you'd never have to make if you completely trusted your caller, 
use
Preconditions.
* For any check which should absolutely never fail in production no matter 
what, use
the Java assert facility.
* For all other checks, use ______.

The blank could be filled in with

Invariants.invariant()
Expectations.expect()
Expect.expect()
Checks.check()

As for your Predicate idea, I think it's good, but Predicate is not quite the 
right
construct because once you start using a complex one, you then get no feedback 
at all
about what part of the complex predicate failed.  My long-term goal is to 
expand the
concept of com.google.common.collect.Constraint to become something that is 
perfect
for this use case as well as validating *user* input which is a whole other 
beast.

Original comment by kevin...@gmail.com on 25 Mar 2009 at 3:32

[GoogleCodeExporter]

Thanks for the quick feedback, Kevin.

> For any check which should absolutely never fail in production no
> matter what, use the Java assert facility

> For all other checks...

You seem to imply that there some checks that would be OK to fail in 
*non-production*
environments, or that there are some that *are* OK to fail in production
environments.  Do you really mean this?  IMHO, a check is a check is a check.  
If
it's in the code, it should never fail.

I would also argue that the Java assertion facility isn't the best option for
catching those "which should absolutely never fail in production", because code 
can
always be run (and probably *would* be run) in production with assertions 
turned off
(it depends; if the code is QA'ed with assertions on, then it goes into 
production
that way, and vice-versa).

I haven't looked at Constraint much.  I'll do that now.  I see your point about 
not
knowing where a complex predicate failed, but I think I would take the ability 
to
express all my checks as a centralized, reusable Predicate with that caveat.  
The
ability to use an enhanced Constraint could be added later, if needed.

Of course I have that ability now:

checkArgument(myPredicate.apply(myObject));

but it would be nice to be able to say:

checkArgument(myPredicate, myObject);

Admittedly, not much more compact, but that about:

checkArgument(Predicates.notNull().apply(obj1));
checkArgument(Predicates.notNull().apply(obj2));
checkArgument(Predicates.notNull().apply(obj3));

versus:

checkArgument(Predicates.notNull(), obj1, obj2, obj3);

Original comment by russ.mil...@gmail.com on 25 Mar 2009 at 4:07

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:57

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 6:02

• Added labels: Milestone-Post1.0

[GoogleCodeExporter]

This issue has been moved to the Guava project (keeping the same id number). 
Simply replace 'google-collections' with 'guava-libraries' in your address 
bar and it should take you there.

Original comment by kevinb@google.com on 5 Jan 2010 at 11:09

• Changed state: Moved