Hi Scott, You draw an interesting parallel. From the programmer's perspective, yes, it might seem like a similar situation. and I guess that's why this question comes up on the mailing list again and again.
It's really fairly different, though. Facts are pattern-matched at the time they are asserted. Once a fact is asserted, it's never supposed to change (except via modify, of course) and so the pattern match is never rechecked. If you match against a defglobal, you're comparing the fact with the value of the defglobal *at the time the fact is asserted,* and subsequent updates to the value of the defglobal won't affact the match. Basically, making this change would mean storing defglobals in the working memory rather than off to the side, the way they are now. This isn't actually a terrible idea -- in fact, it's one that I've thought about on occasion -- but it does deviate significantly from the behavior of related systems like CLIPS. As is usually the case when compatibility issues come up, I'll throw this out for discussion. Should defglobals be "live" with regards to pattern matching? This would undoubtedly break some existing code. If you've got such code, what do you think? Anyway, for now, if you want an object whose state you can change and thereby revise pattern matches, don't use a defglobal. Instead, use either a plain old fact, or use a definstance. A definstanced Java Bean is particularly convenient for this. I think Scott Gallant wrote: > Does the description you give correspond to defglobals as well? I > notice that my predicates that reference a defglobal don't get tickled > when modifying defglobals in the action of the rule. I would appreciate > the described change if so. > > Scott > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > On Behalf Of [EMAIL PROTECTED] > Sent: Thursday, May 09, 2002 2:28 PM > To: Jess Mailing List > Subject: JESS: Behavior of (modify) > > Hi folks, > > In Jess 6, for static definstances, the (modify) function behaves in a > possibly surprising way. This is -not- a bug report; I'm just asking > here what people think of the current behavior. > > Anyway, for static definstances, (modify) modifies the definstanced > object immediately, but the corresponding shadow fact doesn't change > until a (reset). This has probably bit any number of people -- I don't > think they expect this bahavior. > > I'd like to change (modify) to behave uniformly for all kinds of facts > -- i.e., the shadow facts for static definstances would change > immediately. Does anyone depend on, or especially like, the current > behavior instead? > > --------------------------------------------------------- > 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] > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
