Hi Ernest,
Here is the latest Jess misbehaviour I found. It is also
related to Java Bean properties, specifically to "modify" function.
I use simplified example:
---------------------------------------------
(defclass fact example.JavaBean)
(definstance fact (new example.JavaBean))
(defrule r1
?f1 <- (groups $?g price ?p)
?f2 <- (fact)
=>
(retract ?f1)
(modify ?f2 (groups $?g) (price ?p)))
(defrule r2
?f1 <- (index ?i)
?f2 <- (fact)
(not (groups $?))
=>
(retract ?f1)
(modify ?f2 (index ?i)))
(assert (groups 1 2 price 12.34))
(assert (index 1))
Initial fact list:
(fact (groups ) (index 0) (price 0.0))
(groups 1 2 price 12.34)
(index 1)
Note:
I use zero length array initialization for multislot
"groups".
After firing rule r1 (modifies "groups" and "price"):
(index 1)
(fact (groups 1 2) (index 0) (price 12.34))
After firing rule r2 (modifies "index"):
(fact (groups ) (index 1) (price 0.0))
----------------------------------------------------
It seems that "modify" function has a side effect of setting
certain already modified slots/multislots back to their
initial values. These slot/multislots are the ones not listed
as parameters to "modify".
I tried to go back to Jess 4.3 but the effect is the same as
in Jess 5.0a3.
Thanks in advance.
Miroslav Madecki, I/T specialist - RS/6000
Internet: [EMAIL PROTECTED]
Tel: +385-1-6308-156, Fax: +385-1-6111-119
IBM Croatia, Lastovska 23, 10000 Zagreb, Croatia
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list. List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
