[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 
methods.

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 
doing.

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