I've found that the method below behaves differently in Jess 7.0b7 and
the formal v7.0 release. In the formal release, the Activations
provided by the Iterator in 2 successive calls to Rete.listActivations()
are different objects, even if nothing has happened between the calls.
The change has ramifications for those with custom Strategy
implementations. In our case, we scan the agenda for a particular
Activation to favor before calling run(), and then our Strategy's
compare() method tests its arguments for that object with the == operator.
We can, with some impact on performance (presumably negligible on short
agendas), use the Activation.equals() method instead of the ==
operator. But I wanted to ask about the intent of the change, and
whether it's likely to be permanent. I hadn't seen (but could have
simply missed) mention of it in the notes since beta 7. Thanks very much,
Jonathan
________
public void dumpAgenda(String label) {
Map actMap = new HashMap();
Iterator it = listActivations(); // get the agenda and
store Activations
for (int i = 0; it.hasNext(); ++i) {
Activation a = (Activation) it.next();
actMap.put(new Integer(a.hashCode()), a);
}
it = listActivations(); // get the agenda again; no
intervening activity
for (int i = 0; it.hasNext(); ++i) {
Activation a = (Activation) it.next();
Activation aa = (Activation) actMap.get(new
Integer(a.hashCode()));
System.out.println("agenda a["+i+"]"+
(aa == null ? " not" : "")+" in map,"+ // aa !=
null in both v7.0b7 and 7.0
(a == aa ? "" : " not")+ " same obj"); // aa == a
only in v7.0b7
}
}
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify [EMAIL PROTECTED]
--------------------------------------------------------------------
