I don't use CLIPS anymore but I never used it heavily to begin with.
When I did use it, we had a distributed blackboard system based on CLIPS
where facts sent to the blackboard were "reflected" to interested modules.
In this case, everyone had different fact-ids but worked with the same
logical entities. This worked well and did not depend on fact-ids per se.
Within each module there may have been some dependencies on fact-id behavior
but I am not aware of any ;-D
I view these changes as favorable since current behavior of (modify-fact)
doesn't make sense to me anyway.
See other comments inline.
alan
> In fact, if fact-id's didn't change, I can think of lots of internal
> optimizations that could make Jess even faster. One is that RU.FACT_ID
> values could contain a reference to the Fact object itself, saving
> many lookups. In fact, the separate representation of a fact-id as an
> int could go away entirely: an RU.FACT_ID could simply call
> getFactId() on the embedded Fact.
[alan]
I plead ignorance here, but how does this affect activation? I presume
existing agenda items that were activated with the old "version" of the
fact(s) they matched on would have their patterns re-evaluated as before.
Newly matched patterns would also activate.
How would I recognize a rule(s) that depended on the fact-id changing? Would
they have to have explicit use of fact-ids such as stashing them in other
facts, etc.?
>
> Anyway, it turns out this is very easy to do. Only one routine in Jess
> actually cares if the fact-ids change, and it is easily modified to
> not care.
[alan]
If the change isolated, could it not be configured via a compatibility
switch?
Sorry, I had to ask D-;
> Some other fact-related changes: currently all deftemplates, ordered
> and unordered, inherit from a deftemplate __fact with no slots. This
> isn't very useful. It could be much more useful if it were changed a
> little. For instance, what if __fact had a slot (id) which contained
> the fact-id? Then you could eaily find a fact with a given ID.
[alan]
Since defclass is-a deftemplate is-a fact (?), would the id slot for
definstances be the object reference, possibly redundant with the OBJECT
slot?
(defrule find-object
?this <- (type (slot1 ?value1) (slot2 ?value2))
(looking-for ?this)
=>
(call ?this method)
(assert (found ?this))
)
The id namespaces are different so I don't think this would be possible
unless facts were changed to use the underlying references as their id's.
>
> What if __fact had a slot (head) which contained the "head" or name of
> the fact. Then you could find all facts of a given type, with the type
> being runtime data.
[alan]
Does this mean I could somehow distinguish between multiple definstances of
the same object reference. For example, given an object instance A that
implements interfacesX and interfaceY, I would like to "definterface" the X
and Y interfaces separately like so:
(import interfaceX)
(import interfaceY)
(deffunction doit (?x ?y)
(definstance ?x (head interfaceX.class.toString())
(definstance ?y (head interfaceY.class.toString())
)
I would like to be able to write rules that work with interfaces and that do
not depend on (or in addition to) the underlying object identity?
> What if __fact were the parent of deftemplates __ordered, which was
> the parent of all ordered deftemplates, and the slot 'data' that all
> ordered deftemplates have were moved up to the parent? Then you could
> find any ordered fact containing a given datum, regardless of head.
[alan]
Could you give a concrete example of how an existing rule could be rewritten
to exploit these changes or how something that is not currently possible
could be accomplished?
In any case, it sounds useful to me...
> I think all of these would be more or less transparent to existing
> code, but the features would be available. Again, opinions and
> suggestions are invited.
[alan]
Are stupid questions ok?
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
