"Dieter Maurer" <[EMAIL PROTECTED]> wrote:

> I fear your must describe your proposed change more precisely:

Nothing to be afraid of here ;o)

>   When your problem is the stated use case: "verifyObject" fails
>   because something necessary for the interface to be properly implemented
>   is missing in the test but available in a real environment,

Yes, this is what I'm talking about.

>   I would say: that is very fine: Do not change "verifyObject" but
>   give the test instead the resources expected to be available in the
>   real environment.

I think this line of reasoning intermingles two different things to be
tested: the existence of an implementation of an attribute (as a data
descriptor, whatever its getter method tries to do), and whether the
attribute's value is sensible at any given point of time.

You can compare this to a plain attribute promised by an interface: if
it exists on an object that claims to provide the interface,
verifyObject will be happy. The attribute's particular value at the time
verifyObject looks at it may still be something very stupid from the
point of view of the application. The latter is the subject of a
different test, not one of interface implementation.

To put it differently: If I implement a class and give its instances
all attributes defined by a given interface then I expect verifyObject
to damn well see that those attributes are there, without having to do
all sorts of stuff in a completely different part of the code just in
order to satisfy verifyObject's implementation. I'm aware that this is
purely from the point of view of the user and does not take into
account any design discussions that may have taken place when
verifyObject was created.

>   When you want to provide a better (more informative) exception
>   (not "fails to implement" but "ComponentLookupError"), then I am with you.

This would be better than the current behaviour, but it would still lie
because of the difference between the existence of an implementation of
the attribute in question and its successful execution in a given set
of circumstances.


Thomas Lotze · [EMAIL PROTECTED]
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development

Attachment: signature.asc
Description: PGP signature

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to