[Zope3-dev] Re: Merging schema & interfaces (was: "Sub interface")

[Casey Duncan]

On Tue, 02 Mar 2004 10:29:56 -0500
Gary Poster <gary at modernsongs.com> wrote:

> 
> 
> Jim Fulton wrote:
> 
> > To deal with constraints on multiple fields, we will add the ability
> > to model interface/schema-level invariants/constraints.
> > 
> > def cityStateZip(contact):
> >     pc = lookupPostalCodeFor(contact.city, contact.state)
> >     if pc != contact.postal_code:
> >        raise InvalidPostalCode(contact)
> > 
> > class IContact(zope.interface.Interface):
> > 
> >    postal_code = ...
> >    city = ...
> >    state = ...
> > 
> >    invariant(cityStateZip)
> > 
> > Then, when we modify a contact, we can check individual
> > field constraints *and* we can check the interface-level invariants.
> 
> We have that now, yes?  We're using it.  The guts are in Zope 3, from 
> when Jim and I pair programmed on it quickly a few weeks ago.
> 
> Zope 3 needs a pattern on how to use the output in forms, and we need
> to figure out how to spell the invariants and possibly build a library
> of these.
> 
> We have a first stab on how to do this.  One of our interfaces has
> 
>      invariant(isGreater(
>          "expiration_date", "publication_date",
>          _("${field1} must be later than ${field2}")))

I seems to me like this would generate an excessive amount of trivial
code. I'd be inclined to use a lambda in simple cases and a function in
more complex ones as above::

  invariant(lambda thing: thing.expiration_date >
thing.publications_date,
            'Expiration date must be later than the publication date')

More complex invariants could be written like Jim's example. Something I
find a bit strange about that though is that "cityStateZip" becomes like
an instance method defined as a function assigned to the interface. Its
a bit funky conceptually, it certainly stretches the notion of what an
interface is.

-Casey