Martijn Faassen wrote:
Martin Aspeli wrote:

Martijn Faassen wrote:
Oh, I disagree. It's much nicer to be able to be able to start with adapting classes, and introduce interfaces later, where necessary. Often they're not. In fact it's already possible to adapt classes and register views for classes. In ZCML I believe there's some limitations with one directive or other (a bug), at least there was, but the component architecture has allowed this for a long time. We've been very happily using this in grok.

I see your point of view - and I guess there is a balance here.

y'all agree. :)

However, I
think that one of the big benefits we see in Zope2/CMF/Plone over "the old
way" is that people seem to take interfaces more seriously now, and with
them internal documentation. Having well-thought-out and well-documented
interfaces encouages API stability and re-use

Yup, assuming that that is a goal.  Sometimes, it isn't.

and makes it easier to understand someone else's code.

Likewise. :)

>> By contrast, we often end up with
jungles of
APIs and no-one can quite decide whether they're stable or not, when
programmers are given no hooks on which to hang their design.

That can happen with interfaces too.

Yes, but with Plone and CMF and Zope 2 we already have a lot of existing classes, so it makes sense to introduce interfaces: it is more clear what they should be.

It's a lifecycle thing; early on in a project explicit interfaces may be overkill. If a project never grows beyond a certain size it might be permanent overkill, actually. Later on in a project where extensibility and explicit specification and programming by third parties and so on becomes important interfaces make lots of sense.

Do as you wish, of course. I find that abstract discussions like this
typically end up being a lot of talk over apparent disagreement that
disappears when it comes down to practical design.

Of course. It's all a matter of tradeoffs. Disagreement does exist in practical design as well though. In particular, the Zope 3 explicit interfaces and components everywhere approach sometimes leads to overengineering where simple Python patterns would've done much better.

Let's please not call this the Zope 3 approach.  As Pope, I officially
declare that the Zope 3 approach is interfaces and components
(and doctests) where appropriate. :)


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to