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
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
[email protected]
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
