Hi Reinhold,
In addition to verifyClass and verifyObject, I am developing a module for doing
realtime typechecks. I am using a first version of it for one application and it
works great.
I have made a proposal and readme for it, which I have attached. Is this what you
are looking for?
Marc
Op 18-5-2006 8:23, Reinhold Strobl schreef:
Hi,
what I am looking for is something like PyChecker for Zope interfaces. I mean
PyChecker aims to address the benefit of static typed languages and their
compile-time checkings.
In Zope, there is no forced interface compliance. But is there a possibility or
program, which can check this?
Thanks!
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
TypeCheck of Interfaces
Status
IsProposal
Author
Marc Rijken
Problem/Proposal/Goals
In interfaces the behaviour of methods and attributes is been described. It
would be nice if this desciption
could be used for checking the behaviour of implemented methods/attributes.
In fact, my proposal consist
of:
1. describe at the level of the implemented method/attribute the interface
and not on the class level,
so it is always clear which interface describes the intended behaviour
of the implemented
method/attribute
2. use the docstring of the interface to extend the docstring of the
method and put in a
reference to the interface automatically based on 1.
3. use the interface for checking the behaviour of the method/attribute on
runtime.
Proposed Solution
1. use 'implement' at the method level in stead of 'implements' at the
class level. I.e.::
class Test(object):
@implement(ITest)
def add(self, x, y):
return x+y
@implement(ITest)
def multiply(self, x, y):
return x*y
@implementGetter(ITest['at'])
def _getAt(self):
return self.i
@implementSetter(ITest['at'])
def _setAt(self, value):
self.i = value
at = property(_getAt, _setAt)
in stead of::
class Test(object):
implements(ITest)
def add(self, x, y):
return x+y
def multiply(self, x, y):
return x*y
def _getAt(self):
return self.i
def _setAt(self, value):
self.i = value
at = property(_getAt, _setAt)
The decorators `implement`, `implementGetter` and `implementSetter`
acts like implements.
2. `implement` changs also the docstring of the implemented method. Ie::
class ITest(Interface):
def add(x, y):
add two parameters
def multiply(x, y):
multiply two parameters
class Test(object):
@implement(ITest)
def add(self, x, y):
return x+y
@implement(ITest)
def multiply(self, x, y):
a test implementation
return x*y
would give the following docstring for Test.add.__doc__::
Interface ITest, method add
add two parameters
and would give the following docstring for Test.mulitply.__doc__::
Interface ITest, method multiply
multiply two parameters
a test implementation
3. In order to use the interface for typechecking, I propose to use the
TypeCheck
module (see http://oakwinter.com/code/typecheck/). This can be used
easely, when
'implement' works like 'accepts' and 'returns'. The parameters for
accepts and returns
has to be added to the interface. For example::
class ITest(Interface):
@accepts(int, int)
@returns(str)
def add(x, y):
add two parameters
@accepts(float, float)
@returns(float)
def multiply(x, ysdx):
multiply two parameters
In accepts or returns you can give any type or class. The parameter of
the
method will be checked for beiing an instance of that type or class.
But it is
also convenient when it is possible to give the interface which has to
be
implemented by the parameter. So the parameter is checked like in
ITest.providedBy(par1).::
class ITest2(Interface):
@accepts(ITest, ITest)
@returns(ITest)
def add(x, y):
add two parameters
This usage can be a problem when the interface
