Mark,
I thought about what we discussed regarding the OTN creation and the
rule adding. My considerations are:
1. It is possible to map the class hirarchy in an oriented graph during
fact assertion, and this way, when adding a new rule with new OTNs, we
can iterate only over existing object type nodes that might contain
objects that are "assignable from" the new OTNs. Although:
1.a. this algorithm is pretty complex and there is an assertion
(runtime) cost associated to it, since every time a fact of a new
unknown concrete class is added to the WM we need to map the class
hirarchy and add it to the graph.
1.b. there is also a cost associated to the adding of a new OTN (when
adding a rule) since we need to run over the graph updating it to
include the added OTNs
2. We can stop supporting class hirarchy, but as I said before, I would
be completelly against it. I use this a lot to avoid writing multiple
rules, one for each possible concrete class, when I can instead simply
write a rule for a superclass or interface.
3. We can simply hold all facts asserted in a list inside working
memory, independent of class (as we already do), and when adding a new
rule, iterate over all facts checking if it should be asserted to the
new OTN. This imposes a cost when adding new rules, but on the other
side, has no effect on usual modus operandi.
My suggestion is to go with #3. Easy and quick to implement and will
cause no impact on the most common use case: immutable rule base. Then,
after RC and maybe final, we can research a strategy to implement #1 in
a more robust way then the one I thought already (oriented graph).
Let me know what you think. If we go with #3, I can do it relativelly
quickly I believe.
[]s
Edson
PS: if anyone else has any suggestion, just let us know. They are all welcome.
---
Edson Tirelli
Auster Solutions do Brasil
@ www.auster.com.br
+55 11 5096-2277 / +55 11 9218-4151
