[Zope3-dev] Re: Allowing views to be registered for classes rather than interfaces.

[Martijn Faassen]

Jim Fulton wrote:
> >I suspect the problems arise because we have a lot of small objects and
> >code fragments interacting with each other; the patterns in which they 
> >dance are frequently complicated and hard to remember.
> 
> By far, the common case is that you have 2 objects, a view, and the
> thing it's viewing. The component architecture simply separates these into
> two objects. The pattern is very simple.

In a realistic application I don't just develop 2 objects, a view and
the thing it's viewing. I develop a whole range of interoperating
objects.

> >Where Zope 2 has overly
> >fat objects and interfaces and a problem as a result, Zope 3 has overly
> >complicated patterns and interfaces where none are yet needed.
> 
> Could you give an example?

I'm forced to create an interface for just about any object otherwise
it won't play along with the component architecture. Normally I'd 
want to wait until I create interfaces until the problem is clear, but
now I need them as I need to provide, say, a view. I'm not that
good at abstract design.

> > Code
> >evolves from ill-defined patterns that are closely tied together to
> >more pluggability as it turns out to be needed. With Zope 3 at present
> >one is forced to support endless pluggability right from the start.
> 
> This is FUD.

You think I have an agenda about seeding Fear, Uncertainty and Doubt
about Zope 3 now? I would've expected a more generous explanation
where you thought I was trying to contribute. You don't like what
you're hearing, and I may be full of crap, but come on.

>  What sort of "endless pluggability" are you forced to
> support? Does the contact example support "endless plugability"?

Sure, I just want to create a contact application and I can adapt it
to the starship enterprise if I so choose. Note that I think this
is powerful and great, but not when I'm just whipping up a quick
application.

> While I think that there is *some* merit to the argument that you and
> Phillip are making that you should be able to write a view or adapter
> against an implementation, rather than an interface. I think the
> sweeping characterizations you are making are inaccurate and unhelpful.

The problem is that my concern is not one of specifics, so I out of
necessity have to be sweeping. Yes, I'm vague. No, I'm not pointing
out specific problems; they'll always have specific solutions. 

I'm trying to be helpful, I'm sorry I'm seen as unhelpful.

> >Admittedly his is far more common with Zope 3 framework code than Zope 3
> >application code -- but since the Zope 3 framework is in many ways a Zope 
> >3 application it still has me worried.
> 
> You got frustrated by a bit of the framework code that has some essential
> complexity to deal with a hard, but important problem.  The complexity
> of this code arises from the problem it is addressing (automated software
> installation), not from the way the software is created.

I think that design is flawed, and that the costs of the solution outweigh
the benefits. I already pointed out some alternatives in private email.

What I am now sincerely worried about is that this kind of 'essential
complexity' will make its way into my application code. I dealt with
a reasonably complicated Zope 3 application (the services implementation)
and I got hopelessly lost. It was an extremely frustrating experience,
and I don't want this, or even half of this, to become part and parcel of 
Zope 3 development. I do not agree that the complexity I ran into was solely 
caused by the complexity of the application domain.

> >So I propose the following:
> > 
> >   * each class implements its own unique marker interface
> >
> >   * this interface is just 'there' for importing from some obvious
> >     location.
> 
> So the programmer doesn't have to implement it.
> 
> I think you are asking for what Phillip suggested,
> the ability to register a view for a class, rather than
> an interface.

I thought it would be simpler and more conceptually pure to simply create 
an interface, but in effect this would be unique to the class. 
> 
> >   * It's also easy to refer to this interface from ZCML.
> 
> Presumably by just refering to the class.

That would be one way, and may very well be the easiest.

> >The advantage of this proposal is that the whole interface tree
> >remains where it is, but can still be forgotten about when writing
> >new code. It cuts down on one typical location in the interface tree,
> >view tree, content tree triad.
> 
> But leaves the extra view tree, which is still a hassle.

Yes, see next paragraph.

> >Possibly a similar pattern can be followed for default views that
> >are just 'there'. I don't know what that would look like, but it might
> >leverage schema/forms without requiring the extensive directives.
> 
> Explicit is better than implicit. No magic please.

Magic that is explicitly invoked is fine. If I'm able to say
"this object should go on fully automatic" and then stuff just happens,
I asked for it. Right now there is magic but I have to write
larger long and cumbersome incantations for it (long ZCML statements
informing the form machinery).

> >There's a tradeoff in programming; you can get the job done in a nice
> >pluggable reusable way, or you can get the job done *quickly*. Zope 3
> >is very good at the former, but it should improve the latter a lot.
> >Often it has been said that various ZMI features will solve this,
> >and I'm sure they will help, but the same must the case from Python.
> 
> I'll note that an important benefit of interfaces aside from plugability
> is a clear specification of what the contract is.  With interfaces, I
> have much better separation of concerns.  I know how I can change an 
> implementation
> because I know what it's contract is.  Certainly all code in the core
> should have clear contracts.

Obviously there is a clear benefit in interfaces. I'm not debating this.

The way *I* write software often I cannot specify a clear contract before 
the code has evolved somewhat. I am not alone in this; not everybody can
write a perfect abstraction straight away. In my mind the core code
could follow this development pattern as well, instead of expecting
interfaces to spring up from our foreheads fully formed.

Regards,

Martijn