id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
12	schema checks as precondition tools	Brian Warner		"robk would like the following function:

{{{
def check(constraint, target):
    try:
        constraint.checkObject(target, True)
        return True
    except Violation:
        return False
}}}

I'm thinking that it would be slick to put this sort of stuff into a decorator, so that you could define your method as:

{{{
    @schema(a=str, b=ListOf(int), _return=bool)
    def do_something(a, b):
        print a + "" string only""
        print ""maximum b"", max(b)
        return True
}}}

The {{{@schema}}} decorator should do two things:
 * wrap the method with some precondition/postcondition checks that enforce
   the schema on both ends
 * set a method attribute that foolscap's deserialization mechanism can see,
   so that it can enforce the schema on the inbound tokens as they arrive,
   before they are deserialized.

This approach moves the constraint closer to the method definition, which has
its advantages: programmers can glance upwards to see the conditions they
know they can rely upon, and thus don't have to add code to enforce those
constraints themselves. This also allows constraints to be attached to some
methods but not to all of them, and would allow constraints on standalone
functions (not just on methods of class instances).

On the other hand, the RemoteInterface approach has advantages too. It moves
the interface away from the implementation, but by doing so it means that the
interface is a concentrated bundle of documentation, which is easy to publish
and reference. For one program, I implemented the server half of it and
emailed the RemoteInterface .py file to zooko, and he implemented the client
half of it without seeing any details of the server implementation.
InterfacesAsDocumentation is a useful thing.
"	enhancement	new	major	undecided	schemas	0.1.5