[PEAK] Inheritance and @when from PEAK-rules

Athanasios Anastasiou athanasios.anastasiou at plymouth.ac.uk
Mon Jul 16 12:56:03 EDT 2012

Hello everyone

I have been using PEAK-rules with functions but i came across some 
strange behaviour when it came to using it with classes and inherited 

The problem (in one line) is that i find it difficult to get @when to 
call the "right" (overriden) function.

I wish to define an abstract class with a number of calls depending on 
the type of the parameters once and then modify the functionality of 
derived handlers later depending on what each handler is supposed to be 

What i am doing at the time is roughly this:

class someAbstractClass(object):
	def theFunPrototype(self,p1,p2,p3):
		print "Abstract call - unhandled %s %s %s" % (type(p1),type(p2),type(p3))

	@when(theFunPrototype, (int,int,int))
	def _theFunProtoForInts(self,p1,p2,p3):
		print "All three parameters are integers"

	@when(theFunPrototype, (int,int,str))
	def _theFunProtoForIntStr(self,p1,p2,p3):
		print "Two integers and one string"

class someConcreteClass(someAbstractClass):
	def _theFunProtoForInts(self,p1,p2,p3):
		print "Overriden handler %s %s %s" % (p1,p2,p3)

someConcreteClass().theFunPrototype(5,6,7) will execute the 
someAbstractClass' method. If i wanted this thing to work as expected, i 
would have to override a "dummy" theFunPrototype which would call its 
corresponding "super" and add a @when on the derived 
"_theFunProtoForInts" but this seems a bit like duplicating the exact 
same thing on the derived class without any reason...Since both classes 
share a _theFunPrototypeForInts, the right behaviour would be to call 
the derived class....(or maybe not? :-) ).

Any ideas about where i could be going wrong?

Looking forward to hearing from you
Athanasios Anastasiou

More information about the PEAK mailing list