Re: SVN: Zope/trunk/ Moved two implements declarations from Five into the proper classes.
Hanno Schlichting wrote:
Log message for revision 80945: Moved two implements declarations from Five into the proper classes.
I object to this change. HTTPRequest does not really fulfil the IBrowserRequest interface, and ObjectManager isn't a real IContainer either. I understand that somebody made a mistake when they declared them as such in the early days of Five. This is the reason we can't take it back. But, at least as a sign of the fact that they're not (yet) the real deal, this declaration has remained in ZCML. A sensible step forward would be to make HTTPRequest a full IBrowserRequest (we're getting there). As for ObjectManager, I think IContainer implies a couple of semantics (such as unicode names, the sending of events, etc.) that we should look closer at before deciding. -- http://worldcookery.com -- Professional Zope documentation and training
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote:
Hanno Schlichting wrote:
Log message for revision 80945: Moved two implements declarations from Five into the proper classes.
I object to this change. HTTPRequest does not really fulfil the IBrowserRequest interface, and ObjectManager isn't a real IContainer either. I understand that somebody made a mistake when they declared them as such in the early days of Five. This is the reason we can't take it back. But, at least as a sign of the fact that they're not (yet) the real deal, this declaration has remained in ZCML.
A sensible step forward would be to make HTTPRequest a full IBrowserRequest (we're getting there).
I'm note sure we can get there: the 'traverse()' method, for instance, has incompatible semantics. We might be better off making an adapter, and tweaking the Z3 publisher to adapt the request before looking up things against it.
As for ObjectManager, I think IContainer implies a couple of semantics (such as unicode names, the sending of events, etc.) that we should look closer at before deciding.
Don't konw about that one. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHG3sY+gerLs4ltQ4RAj6AAKC/6HKHN4iTq0gZSro1BMg3xKpi+ACeOItY zaR5FrBy/C1MGRc8TKJL6IA= =5l3C -----END PGP SIGNATURE-----
Philipp von Weitershausen wrote:
Hanno Schlichting wrote:
Log message for revision 80945: Moved two implements declarations from Five into the proper classes.
I object to this change. HTTPRequest does not really fulfil the IBrowserRequest interface, and ObjectManager isn't a real IContainer either. I understand that somebody made a mistake when they declared them as such in the early days of Five. This is the reason we can't take it back. But, at least as a sign of the fact that they're not (yet) the real deal, this declaration has remained in ZCML.
Hiding the interface declaration in some exotic place in ZCML isn't very helpful IMO. We can add a comment to the implements directive in both classes that these are not implementing the full interface, though. Five isn't just an add-on anymore but a core part of Zope2, moving things into the proper places, should make it easier for those people, who haven't followed the whole history of Five.
A sensible step forward would be to make HTTPRequest a full IBrowserRequest (we're getting there). As for ObjectManager, I think IContainer implies a couple of semantics (such as unicode names, the sending of events, etc.) that we should look closer at before deciding.
All sounds fine as next steps, hopefully someone is willing to put some work into it. My main motivation besides making things more easily discoverable was speed increase. For some reason five:implements or classImplements is the slowest of all CA actions, when combined with complex classes. Moving these two statements to the classes themselves, made them take just the 75th fraction of time then before. Hanno
Hanno Schlichting wrote at 2007-10-22 09:43 +0200:
Philipp von Weitershausen wrote: ...
I object to this change. HTTPRequest does not really fulfil the IBrowserRequest interface, and ObjectManager isn't a real IContainer either. I understand that somebody made a mistake when they declared them as such in the early days of Five. This is the reason we can't take it back. But, at least as a sign of the fact that they're not (yet) the real deal, this declaration has remained in ZCML.
Hiding the interface declaration in some exotic place in ZCML isn't very helpful IMO. We can add a comment to the implements directive in both classes that these are not implementing the full interface, though. Five isn't just an add-on anymore but a core part of Zope2, moving things into the proper places, should make it easier for those people, who haven't followed the whole history of Five.
I often disagree with Philipp but I, too, feel it is wrong to use "implements(...)" when the class does not implement "...". All declarations should be trustable -- otherwise, you could forget about interfaces alltogether... -- Dieter
Dieter Maurer wrote:
I, too, feel it is wrong to use "implements(...)" when the class does not implement "...".
All declarations should be trustable -- otherwise, you could forget about interfaces alltogether...
On some occasions you just can't fulfill an entire interface, and for whatever reason can't or don't want to create a super interface that you *can* fulfill so you do the best you can and raise NotImplemented when you can't. I don't know anything about this situation, so I don't know if that approach is warranted here. -- Benji York Senior Software Engineer Zope Corporation
Hanno Schlichting wrote:
Philipp von Weitershausen wrote:
Hanno Schlichting wrote:
Log message for revision 80945: Moved two implements declarations from Five into the proper classes. I object to this change. HTTPRequest does not really fulfil the IBrowserRequest interface, and ObjectManager isn't a real IContainer either. I understand that somebody made a mistake when they declared them as such in the early days of Five. This is the reason we can't take it back. But, at least as a sign of the fact that they're not (yet) the real deal, this declaration has remained in ZCML.
Hiding the interface declaration in some exotic place in ZCML isn't very helpful IMO. We can add a comment to the implements directive in both classes that these are not implementing the full interface, though. Five isn't just an add-on anymore but a core part of Zope2, moving things into the proper places, should make it easier for those people, who haven't followed the whole history of Five.
I think that makes sense. Add in these in but *with* a clear comment that this is actually a lie. We simply move the lie to a more prominent place this way, increasing the chances it'll bother people enough to actually working on fixing it. Regards, Martijn
Philipp von Weitershausen wrote:
Hanno Schlichting wrote:
Log message for revision 80945: Moved two implements declarations from Five into the proper classes.
I object to this change. HTTPRequest does not really fulfil the IBrowserRequest interface, and ObjectManager isn't a real IContainer either. I understand that somebody made a mistake when they declared them as such in the early days of Five. This is the reason we can't take it back. But, at least as a sign of the fact that they're not (yet) the real deal, this declaration has remained in ZCML.
A sensible step forward would be to make HTTPRequest a full IBrowserRequest (we're getting there). As for ObjectManager, I think IContainer implies a couple of semantics (such as unicode names, the sending of events, etc.) that we should look closer at before deciding.
I've found the fact that ObjectManager implements IContainer to be a problem in my application where I have a mixin implementing then ObjectManager expectations by adapting to IContainer (this allows most of my code to be zope 3 like with the zope 2 compatibility contained). I've had to subclass IContainer and adapt to my subclass instead. The only place I've run into problems using unicode names is in the ZCatalog (or maybe CatalogTool) where there is a test that a name isinstance str. Laurence
On 10/23/07, Laurence Rowe <l@lrowe.co.uk> wrote:
Philipp von Weitershausen wrote:
Hanno Schlichting wrote:
Log message for revision 80945: Moved two implements declarations from Five into the proper classes.
I object to this change. HTTPRequest does not really fulfil the IBrowserRequest interface, and ObjectManager isn't a real IContainer either. I understand that somebody made a mistake when they declared them as such in the early days of Five. This is the reason we can't take it back. But, at least as a sign of the fact that they're not (yet) the real deal, this declaration has remained in ZCML.
A sensible step forward would be to make HTTPRequest a full IBrowserRequest (we're getting there). As for ObjectManager, I think IContainer implies a couple of semantics (such as unicode names, the sending of events, etc.) that we should look closer at before deciding.
I've found the fact that ObjectManager implements IContainer to be a problem in my application where I have a mixin implementing then ObjectManager expectations by adapting to IContainer (this allows most of my code to be zope 3 like with the zope 2 compatibility contained). I've had to subclass IContainer and adapt to my subclass instead.
The only place I've run into problems using unicode names is in the ZCatalog (or maybe CatalogTool) where there is a test that a name isinstance str.
I guess we need to either actually implement the relevant interfaces, or split the interfaces into something that can be implemented... -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64
Lennart Regebro wrote:
On 10/23/07, Laurence Rowe <l@lrowe.co.uk> wrote:
Philipp von Weitershausen wrote:
Hanno Schlichting wrote:
Log message for revision 80945: Moved two implements declarations from Five into the proper classes. I object to this change. HTTPRequest does not really fulfil the IBrowserRequest interface, and ObjectManager isn't a real IContainer either. I understand that somebody made a mistake when they declared them as such in the early days of Five. This is the reason we can't take it back. But, at least as a sign of the fact that they're not (yet) the real deal, this declaration has remained in ZCML.
A sensible step forward would be to make HTTPRequest a full IBrowserRequest (we're getting there). As for ObjectManager, I think IContainer implies a couple of semantics (such as unicode names, the sending of events, etc.) that we should look closer at before deciding.
I've found the fact that ObjectManager implements IContainer to be a problem in my application where I have a mixin implementing then ObjectManager expectations by adapting to IContainer (this allows most of my code to be zope 3 like with the zope 2 compatibility contained). I've had to subclass IContainer and adapt to my subclass instead.
The only place I've run into problems using unicode names is in the ZCatalog (or maybe CatalogTool) where there is a test that a name isinstance str.
I guess we need to either actually implement the relevant interfaces, or split the interfaces into something that can be implemented...
Preferably not too far down the class hierarchy. It would be useful for things such as cmf's PortalFolder not to implement IContainer directly, it makes non-zodb content much easier if an adapter can be used.
Laurence Rowe wrote at 2007-10-23 12:00 +0100:
Lennart Regebro wrote: ...
I guess we need to either actually implement the relevant interfaces, or split the interfaces into something that can be implemented...
Preferably not too far down the class hierarchy. It would be useful for things such as cmf's PortalFolder not to implement IContainer directly, it makes non-zodb content much easier if an adapter can be used.
Are you abusing adapters? If not, it should not matter whether the object implements an interface directly or whether an adapter is needed... -- Dieter
On 23/10/2007, Dieter Maurer <dieter@handshake.de> wrote:
Laurence Rowe wrote at 2007-10-23 12:00 +0100:
Lennart Regebro wrote: ...
I guess we need to either actually implement the relevant interfaces, or split the interfaces into something that can be implemented...
Preferably not too far down the class hierarchy. It would be useful for things such as cmf's PortalFolder not to implement IContainer directly, it makes non-zodb content much easier if an adapter can be used.
Are you abusing adapters?
If not, it should not matter whether the object implements an interface directly or whether an adapter is needed...
Possibly, but I just want the higher level CMF functionality without assumptions about the lower level functionality (would not be a problem in a pure zope 3 environment). Laurence
participants (8)
-
Benji York -
Dieter Maurer -
Hanno Schlichting -
Laurence Rowe -
Lennart Regebro -
Martijn Faassen -
Philipp von Weitershausen -
Tres Seaver