Hi David,
Jess is intended to behave the way you expect -- calling equals() to
match objects. Look at the method doTest in jess.Test2Simple -- that's
the code that does a simple comparison of two slots in different
facts. It calls jess.Value.equals(). That method, in turn, uses
equals() on the contained object to compare EXTERNAL_ADDRESS values.
If you look at the jess.Value.equals() method, you'll see that the
exact same code path is used for Strings as for EXTERNAL_ADDRESSs.
Nevertheless, something unexpected is happening for you. Try to
produce a full, minimal working example that shows the behaviour and
send it along. I'll be glad to have a look.
I think David E. Young wrote:
> Greetings. I was surprised by something today and would appreciate
> clarification.
>
> Given an unordered fact with a slot that holds an instance of some
> Java class, I had hoped that the test(s) generated for the join nodes
> would employ Object.equals() during pattern matching. In other words,
> given the following code fragments:
>
> public class Schtum {
> ...
> public boolean equals() {...}
> }
>
> (deftemplate rocky
> (slot key))
>
> (deftemplate boris
> (slot key))
>
> (defrule schtum
> (rocky (key ?key))
> (boris (key ?key))
> =>
> ...)
>
> (assert (rocky (key (new Schtum()))))
> (assert (boris (key (new Schtum()))))
>
> I would expect that, assuming Schtum.equals() evaluates to TRUE for
> each of the above instances, rule SCHTUM would be activated. However,
> this assumption does not appear to be correct. I must rewrite the rule
> thusly:
>
> (defrule schtum
> (rocky (key ?key))
> (boris (key ?k&:(eq ?k ?key)))
> =>
> ...)
>
> to affect the expected behavior. Note that class Schtum is *not* a
> bean, and reflects classes in an existing system into which I'm
> embedding a jess engine.
>
> This is probably standard Jess behavior, but I'd like to make sure.
>
> Regards,
>
> --
> -----------------------------------------------------------------
> David E. Young
> Fujitsu Network Communications (defun real-language? (lang)
> ([EMAIL PROTECTED]) (eq lang 'LISP))
>
> "The fact that ... we still
> live well cannot ease the pain of
> feeling that we no longer live nobly."
> -- John Updike
>
>
> ---------------------------------------------------------------------
> 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]
> ---------------------------------------------------------------------
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
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]
---------------------------------------------------------------------