[Zope3-dev] schema initial documentation

[Phillip J. Eby]

At 09:13 PM 4/20/02 +0200, Martijn Faassen wrote:

>   * Jim seemed to have the idea you shouldn't mix fields with methods.
>     So based on that, I figured we should have separate schema interfaces. :)
>     But Jim should jump in and explain his thinking here.

Hm.  Yes.


>   * If you know your schema only contains fields, and not methods, you can
>     actually write code that *implements* the schema. You can't do that
>     with ordinary methods. Schema contain enough information to actually
>     create an object with the right attributes on the fly, however.

Why not just raise an exception if you bump into a method?  Or give 
Interface objects a "hasMethods()" method so you can check?


> > One thing that's rather interesting here; an opportunity for overlap with
> > Features in TransWarp...
> >
> > In TransWarp, a "feature" is a class attribute that can export methods to
> > its containing class, possibly in addition to being a property of that
> > class' instances.
>[snip]
>
>Interesting. I'm not entirely sure I see the overlap with schema, however.
>Do you mean to indicate a parallel between Field and Feature objects, in
>that they're both rather 'intelligent' part of an interface (as opposed to
>simple methods and attributes)?

Sorry, I guess I wasn't expressing myself clearly.  What I meant was that 
I'd like to be able to specify a feature in an interface, and have it imply 
the existence of methods and/or fields in the interface.  Thus, if I added 
a "limbs" feature to "IPerson", it would automatically add the "addLimb()" 
and "removeLimb()" methods to the interface signature.  Here, I'm 
considering that Interface.Attribute and Interface.Method are actually in 
some sense subclasses of Interface.Feature (which doesn't exist yet), that 
signify the addition of only a single method or attribute to the signature.

Of course, I can do this now using an explicit '__metaclass__' specifier to 
build the interfaces, but it'd be nice to have the notion as a standard 
part of documenting interface semantics.  As I said, it's common (for 
example) in the JavaBeans world to just mention a kind of "property" in an 
interface, which implies the existence of a set of methods that implement 
the "property".  CORBA "attributes" and COM "properties" work similarly, 
implying the existence of getters, setters, or other manipulation methods.

This is one of those cases where a more compact representation -- as long 
as its expansion follows clear and uniform rules -- is more effective for 
communication.