[PEAK] Re: gf.when() doesn't honour Interfaces on instances (protocols.adviseObject)

Stephen Waterbury golux at comcast.net
Thu Dec 2 14:40:43 EST 2004

Phillip J. Eby wrote:

> ....  Personally, I think using interfaces 
> to represent state is, well, odd at the least.  An interface expresses a 
> contract, but what is the contract of a state?  State is part of 
> implementation, IMO, not part of the interface.

Wow, I'm so glad to hear you say that, Phillip!  In past
discussions, I have used the term "schema" to refer to a
collection of properties that represent a state, and some
had tried to persuade me that an interface should be used
to represent that sort of schema.

Of course, the term "schema" is very much over-loaded and
*is* used in some contexts for state and in others for
interface, but state was definitely what I was referring
to -- more specifically, persistence services for state.
So I'm very relieved to see your statement above, which
for me perfectly captures the state/interface duality I
was trying to express (in which I had use "schema" to refer
to the structure of a state to be persisted -- e.g., in a
database ;).

Of course, in meta-programming, a "state" could be
the state of an interface -- sure, but at each
meta level there are still states and interfaces, and they
always have the same duality.

> However, I think this is part of a systemic design bias in Zope towards 
> viewing objects as dumb "content", and putting the behaviors in other 
> objects that examine the "content" to decide what to do with it.  I 
> think this perspective leads to flawed encapsulation, and makes it 
> harder for people to extend the framework because they then have to fake 
> metadata to convince the behavior objects to do what they want, when if 
> the behavior were on the content object to start with it wouldn't be an 
> issue.

I also agree with this, and it expresses part of why
I avoid Zope.  To me, this is similar to the conceptual
framework used by game builders, whose objects must have magical
transformation capabilities, so their intrinsic nature is
either non-existent or extremely simple, but they can become
very elaborate depending on what properties/interfaces are
assigned to them as the game progresses.


More information about the PEAK mailing list