I have previously posted about duck-typing and whether or not it should be possible to write a rule that doesn't check the Fact object's class name but instead check the existance of the attributes that are tested in Alpha and Beta nodes.
A couple of months ago I concluded that it's best to leave that sort of thing out and instead require that the rule's definition include class names for each variable.
However, things are not so simple. Just because pyRete won't allow you to compile a "duck-typed" Rete Network doesn't mean the Fact objects passing through it will play nice as well.
Consider the following rule:
>>> @pyRete.ruleand this Fact class:
... def foo(a= Foo):
... if a.n > 10:
>>> class Foo(pyRete.Fact):Using it as defined won't cause any problems but unfortunately (or luckily, depends a bit on how you view the world ;-) there's no stopping this type of behaviour:
... def __init__(self, n):
... self.n = n
>>> obj = Foo(n = 10)That makes it obviuos that the ObjectType node test won't be sufficient for pyRete. Even though the above (using del on an instance's property) is probably rather rare there's no way to *know* if the public interface of the Fact instance has been modified or not.
>>> del obj.n
Traceback (most recent call last):
", line 1, in
AttributeError: 'Foo' object has no attribute 'n'
I think I'm going to have to implement the Rete Network more or less as described in Forgy's 1979 paper where he tests the length and the contents of a Fact object in order to categorize it properly. In the 1982 article it appears as if these tests have vanished and have been replaced by a "type" symbol in the first element of each fact. Which, I believe, is now usually known as an ObjectType node.
Now, the only question is: Should I distribute the tests among the Alpha and Beta nodes or should I extend the ObjectType node with some property existance tests as well?