Re: [Zope3-dev] adaptation based on class rather than interface
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-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
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. 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 and makes it easier to understand someone else's code. 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. 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. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
On 11/9/06, Jean-Marc Orliaguet <[EMAIL PROTECTED]> wrote: Lennart Regebro wrote: > On 11/9/06, Chris Withers <[EMAIL PROTECTED]> wrote: >> Why do you say "extra" ZCML registration? You need that ZCML >> registration whether or not you have to write the marker interface... > > Sure, but with the marker interface you need only one. You need one > for each class, in your example, thats two. So the second one is > "extra". :) > I think it is a mistake to use interfaces to specify what object _are_ as opposed to what they can _do_. It is better to use base classes for that. Yeah, but in this example there are no base classes available, as I understand it. So it's perfectly feasible to marl something with a marker interface to say "this can be adapted to X". It is a "can do" marking, not an "is" marking, IMO. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Martin Aspeli wrote at 2006-11-9 04:37 -0800: > ... >Why does your class not have a (non-marker) interface in the first place? >The use of interfaces as documentation and as formalisms for expressing a >class' functionality (in adapters, utilities etc) is one of the benefits >that Zope 3 introduces. I can see how they may not always add that much >value immediately, but they are a good way of ensuring things are reasonably >well-defined, well-documented and easily locatable. I have quite a different point of view: Interfaces define essentially the signature of methods but these signatures can also directly be derived from the class. Zope3 interfaces are slightly better as they can also specify attributes -- which is very helpful as Python does not provide a good means for this. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Lennart Regebro wrote: On 11/9/06, Chris Withers <[EMAIL PROTECTED]> wrote: Why do you say "extra" ZCML registration? You need that ZCML registration whether or not you have to write the marker interface... Sure, but with the marker interface you need only one. You need one for each class, in your example, thats two. So the second one is "extra". :) I think it is a mistake to use interfaces to specify what object _are_ as opposed to what they can _do_. It is better to use base classes for that. I agree with Chris that making classes adaptable would be simpler. Interfaces were designed to specify what an object can do, e.g. a media player will do: play(), stop(), rewind(), without specifying the actual implementation ... whereas classes tell what objects are (an mp3 player, an LP player, a cassette player, ...), they are more specific to the object. And there is nothing wrong with using inheritance when there is a '__IS A __' type of relation (e.g. an ordered folder IS A folder IS AN item, ...), or if there is a HAS_A type of relation (a folder has items, a chair has four legs...). It seems that Zope3 has banned all form of class inheritance, even those that made sense, and that would have simplified the implementation. "marker interfaces" have empty specifications, that's the problem: they can't grow into "real" interfaces that have a specification. If you add methods to the marker interface you will have to track down all classes that implement the interface (unless you don't really care whether classes do implement their interface). /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
On Thursday 09 November 2006 10:02, Chris Withers wrote:
> ...will work, right?
>>> import zope.component
>>> class A(object):
... pass
...
>>> class B(A):
... pass
...
>>> import zope.interface
>>> class ISomething(zope.interface.Interface):
... pass
...
>>> class BToSomething(object):
... def __init__(self, context):
... pass
...
>>> zope.component.provideAdapter(BToSomething,
[zope.interface.implementedBy(B)], ISomething)
>>> ISomething(b)
<__main__.BToSomething object at 0xb7a4fa4c>
>>> from zope.component.globalregistry import base
>>> base.__init__('base')
>>> ISomething(b)
Traceback (most recent call last):
File "", line 1, in ?
TypeError: ('Could not adapt', <__main__.B object at 0xb7a4f96c>,
)
>>> zope.component.provideAdapter(BToSomething,
[zope.interface.implementedBy(A)], ISomething)
>>> ISomething(b)
<__main__.BToSomething object at 0xb7a4f9ac>
>>>
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
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. 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 and makes it easier to understand someone else's code. 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. 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. Martin -- View this message in context: http://www.nabble.com/adaptation-based-on-class-rather-than-interface-tf2601087.html#a7260124 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Chris Withers wrote: Jim Fulton wrote: I think it is a fine idea. That's why it has been supported for a long time. You can register adapters and views (which, of course are adapters) for classes as well as interfaces. Yay! *sound of a million marker interfaces dying* Hmm, is this documented anywhere? The ZCML docs distinguish between fields that require a GlobalObject vs. a GlobalInterface. When a GlobalObject is required, that usually means you can specify a class instead of an interface. Hopefully, the adapter directive uses a schema that expects a GlobalObject for the "for" field. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Chris Withers wrote: Jim Fulton wrote: I think it is a fine idea. That's why it has been supported for a long time. You can register adapters and views (which, of course are adapters) for classes as well as interfaces. Hmm, just to be clear: class A: pass class B(A): pass x = ISomething(B) ...will work, right? Yes, that should work; it works for us this way in Grok. :) As I said elsewhere, the only thing blocking usage of this in ZCML is some directive which at least used to complain when you passed in a class. That would be a bug. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Martin Aspeli wrote: Chris Withers wrote: I find myself often having to define pure marker interfaces for each class that I define, purely so I can register adapters for objects of that class. Why does your class not have a (non-marker) interface in the first place? The use of interfaces as documentation and as formalisms for expressing a class' functionality (in adapters, utilities etc) is one of the benefits that Zope 3 introduces. I can see how they may not always add that much value immediately, but they are a good way of ensuring things are reasonably well-defined, well-documented and easily locatable. I'd rather start from interface design and implement as necessary, than think of interfaces as necessary evils of the CA, personally. 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. C++ also encourages/enforced the writing of a .h file describing the interface for all classes. I then learned Python and was much happier. Zope 3 should allow for the Pythonic pattern of development. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Jim Fulton wrote: I think it is a fine idea. That's why it has been supported for a long time. You can register adapters and views (which, of course are adapters) for classes as well as interfaces. Hmm, just to be clear: class A: pass class B(A): pass x = ISomething(B) ...will work, right? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Jim Fulton wrote: I think it is a fine idea. That's why it has been supported for a long time. You can register adapters and views (which, of course are adapters) for classes as well as interfaces. Yay! *sound of a million marker interfaces dying* Hmm, is this documented anywhere? Philipp, is this in the new edition of your book? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Chris Withers wrote: Hi All, I find myself often having to define pure marker interfaces for each class that I define, purely so I can register adapters for objects of that class. How do people feel about: - being able to register an adapter as follows: I think it is a fine idea. That's why it has been supported for a long time. You can register adapters and views (which, of course are adapters) for classes as well as interfaces. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Chris Withers wrote: > > Hi All, > > I find myself often having to define pure marker interfaces for each > class that I define, purely so I can register adapters for objects of > that class. > Why does your class not have a (non-marker) interface in the first place? The use of interfaces as documentation and as formalisms for expressing a class' functionality (in adapters, utilities etc) is one of the benefits that Zope 3 introduces. I can see how they may not always add that much value immediately, but they are a good way of ensuring things are reasonably well-defined, well-documented and easily locatable. I'd rather start from interface design and implement as necessary, than think of interfaces as necessary evils of the CA, personally. Martin -- View this message in context: http://www.nabble.com/adaptation-based-on-class-rather-than-interface-tf2601087.html#a7257399 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
On 11/9/06, Chris Withers <[EMAIL PROTECTED]> wrote: Why do you say "extra" ZCML registration? You need that ZCML registration whether or not you have to write the marker interface... Sure, but with the marker interface you need only one. You need one for each class, in your example, thats two. So the second one is "extra". :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Lennart Regebro wrote: Sorry about the premature sending, I don't know what button I pressed... Here we go again: So instead of making a marker interface, which is two lines of code, and two registrations, a total of six lines (with the imports), you have an extra ZCML registration statement, which is three lines of code. So you save three lines of code. Why do you say "extra" ZCML registration? You need that ZCML registration whether or not you have to write the marker interface... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Sorry about the premature sending, I don't know what button I pressed... Here we go again: So instead of making a marker interface, which is two lines of code, and two registrations, a total of six lines (with the imports), you have an extra ZCML registration statement, which is three lines of code. So you save three lines of code. I'm not against your suggestion, but I'm not convinced it's actually useful. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
On 11/9/06, Chris Withers <[EMAIL PROTECTED]> wrote: It's not one to one: Re-use of adapters without having to create or use a mixin... So instead of making a marker interface, which is two lines of code, a I'm not against your suggestion, but I'm not convinced it's actually useful. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Lennart Regebro wrote: On 11/9/06, Chris Withers <[EMAIL PROTECTED]> wrote: I'm expecting people to say "NO!" very loudly, but I'm interested in the real reasons for why this is bad. Well it removes the possibility of switching out the class, which begs the question why you would have an adapter in the first place. If you have a strict one to one relationship between the class and the adapter, why not just implemetent the desired functionality directly in the class? It's not one to one: Re-use of adapters without having to create or use a mixin... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
On 11/9/06, Chris Withers <[EMAIL PROTECTED]> wrote: I'm expecting people to say "NO!" very loudly, but I'm interested in the real reasons for why this is bad. Well it removes the possibility of switching out the class, which begs the question why you would have an adapter in the first place. If you have a strict one to one relationship between the class and the adapter, why not just implemetent the desired functionality directly in the class? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] adaptation based on class rather than interface
Hi All, I find myself often having to define pure marker interfaces for each class that I define, purely so I can register adapters for objects of that class. How do people feel about: - being able to register an adapter as follows: ..in addition to the normal registration for interfaces. - be able to adapt objects based on their class if no interfaces match: class MyClass: pass obj = MyClass() ISomething(obj) I'm expecting people to say "NO!" very loudly, but I'm interested in the real reasons for why this is bad. Having to define interfaces purely so an adapter can be registered seems tortological to me... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
