On Monday 06 February 2006 11:53, Shaun Cutts wrote:
> I've thought of several things I'd like to see in it.... The biggest
> would obviously be (optional) type checking of method calls, together
> with a more robust Method definition.
Yes, there has been suggestions in this direction before.
Obviously this might be a subject for zope.interface.
> Also it would be nice to have
> something like "delegateImplementation( iface, cvar )" and
> "delegateProvision( iface, ivar)" to delegate the fulfillment of an
> interface to a class variable or an instance variable.
I don't understand what you mean.
> But my overall question is: since zope.schema is generally useful for
> components, why is it separate from zope.interface? I can think of two
> answers: one, pragmatically, zope3 wants a stable zope.interface so the
> rest of the system can come up to speed. Thus we can think of schema as
> sort of like the __future__ version of zope.interface. Second, as schema
> came from abstracting away zope-like features from gui support, it is
> meant as "proto-gui-support".
Well, it is a matter of overhead. We don't feel that everyone needs
zope.schema. See the twisted guys for example.
> I would argue that, though it does support some features that would be
> useful for a gui, it is more generally applicable to component-based
If you feel strongly about this, bring it up on the zope.interface mailing
> (I have been using it for-- among other things-- some souped-up database
> Rows, which support transparently some postgress-specific features. The
> extra introspection capabilities in zope.schema have been useful.)
Yep, it is nice for RDB things.
> But maybe Jim resists changes because he has a more specific role in
> mind for zope.schema, and the development of zope.interface?
You have to ask him and the zope.interface mailing list. :-)
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-dev mailing list