Re: JBRULES-94 and JBRULES-95
Michael Neale <michael.neale <at> gmail.com>
2006-04-02 02:30:07 GMT
#3 sounds good. 99% of the time we are not adding/removing rules, so we
don't wnat to impact the 99% of the time with what will happen 1% of the
time !
On 3/30/06, Edson Tirelli <edson.tirelli <at> auster.com.br> wrote:
>
> 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
(Continue reading)