It comes up constantly on this list. One recent instance concerned a
system in which definstances were added in an uninitialized state, and
then various rules set their properties. Each time a property was set,
various initialization rules were re-activated. The rules had to be
written carefully
Oh, now we have another possibility. I guess I was actually thinking of
marking a fact so that changes to it wouldn't activate rules at all, so that
only changes to the (x) fact would trigger count-x-facts. In effect, this
would convert the fact into a variable that nonetheless could be matched
Ernest:
What I have done in the past is to establish a Goal object to control rule flow
such that we assert the Goal objects in the reverse order of rule flow so that the
last asserted Goal will be examined first. This lets the rules control the flow
using the recency of the Goals. If I want to
Please pardon me if I missed part of this discussion by overzealous email
deletions (holiday email cleanup), but is this property more appropriately
attached to the fact, rather than the rule (as is logical)? In the example
below, the count template could be marked so that changes to it won't
Excusez moi,
I have been following the various postings with interest and it seems that
the proposal (for the new one-shot
feature) is really a crutch for projects that can't (or won't) do rules
engineering.
My preference would be to have a tool that can assist with the rules
engineering by
I think Rich Halsey wrote:
On the other hand, depending on the system architecture
or the goal we wish
to achieve, a one-shot rule may be the anti-thesis of what we need.
It seems that you, like James, may have missed the idea that this is
an optional property that you could grant to
to be eligible for firing then I
simply use the rules system as is.
It may be that I'm still confused as to the utility of your proposed
feature.
Thanks,
Rich Halsey
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, January 05, 2003 12:09 PM
Subject: Re: JESS: Re
I think Rich Halsey wrote:
It may be that I'm still confused as to the utility of your proposed
feature.
It comes up constantly on this list. One recent instance concerned a
system in which definstances were added in an uninitialized state, and
then various rules set their properties. Each
Thanks Ernest,
I'll sit quietly in the boat now.
Rich Halsey
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, January 05, 2003 1:24 PM
Subject: Re: JESS: Re: Proposed feature
I think Rich Halsey wrote:
It may be that I'm still confused
OK, now that we're off and running, one-shot seems like it would work for a
limited set of circumstances. However, if we use goal-oriented programming
then we don't need a special set of rules or objects. If we have a specific
goal and the goal exists THEN we do either one or two things:
1. If
But you seem to be ignoring the whole problem, the refractoriness
problem, I think you might call it. Show me how, using Jess's current
semantics, you might accomplish what this rule (using the new feature)
does:
(defrule count-x-facts
(declare (one-shot TRUE))
(x)
11 matches
Mail list logo
