[Zope3-dev] zope.schema: defaults for non-immutables... questions

[Shaun Cutts]

Stephan,

By delegation support I mean support for being a proxy for an interface,
and
delegating its fulfillment to a subobject. For instance (by example):

class ISomeContainer( Interface ): 
    ...

class ISoup( Interface ):
    ...

class SomeContainer:
    implements( ISomeContainer )

class SoupedUpContainer:

    implements( ISomeContainer, ISoup )
    delegateToInstanceAttribute( ISomeContainer, 'theContainer' )

    def __init__( self ):
        self.theContainer = SomeContainer()

    
What "delegateToInstanceAttribute" does is use __metaclass__ to create
member functions in the SoupedUpContainer interface to implement the
ISomeContainer
interface by calling the functions on getattr( self, 'theContainer' )

"delegateToClassAttribute" would create classmethod members that did the
same, except they delegated to a class attribute.

(Note -- these names are more descriptive, but long-winded.)

In my experience, it is quite common to want to delegate one interface
but
not another. Currently, even automating this outside of zope.interface
now takes messing around with the "advise" internals, as a custom
metaclass is called before the class interfaces are set up, where here
we want to do the delegation afterwards. But some mechanism would be
very useful, as proxying code is repetitive and thus boring and easy not
to maintain.

... I will work up a proposal on this at some point, and post about it
to the zope.interface list (which I had overlooked). I just wanted to
explain what I meant in case it caught your fancy.

As for the separation of zope.interface and zope.schema, I don't really
feel
Strongly; I just wanted to know why it was done the way it was done. If
zope.interface provided better hooks (e.g. in advise) that would make
implementing non-core features elsewhere easier.

-----Original Message-----
From: Stephan Richter [mailto:srichter at cosmos.phy.tufts.edu] 
Sent: Tuesday, February 07, 2006 5:15 AM
To: zope3-dev at zope.org
Cc: Shaun Cutts
Subject: Re: [Zope3-dev] zope.schema: defaults for non-immutables...
questions

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.

http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/MethodS
pecification
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Specifi
cationUnification

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
> programming.

If you feel strongly about this, bring it up on the zope.interface
mailing 
list.

> (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. :-)

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training