I think Alexander Lamb wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Well, it looks like the root of all my previous problems is that some
> properties of my definstanced objects can be null (for example, initially a
> user may not have chosen a command, or a medical order might not yet exist,
> etc...).
>
> So, as I understood, instead of doing something like:
>
> (Defrule rule1
> (myObject
> (user ?x & :(eq "Alex" (get ?x name)))
> =>
> ...
>
> I will rather do:
>
> (defrule rule2
> (myObject (user ?x)))
> (User (OBJECT ?x) (name "Alex"))
> =>
> ...
Yes, this is a good way to get around the problem. It's pretty similar
to what you'd do in Java. If the "user" property can be null, you
can't say
if (user.getName().equals("Alex"))
...
you have to say
if (user != null &&
user.getName().equals("Alex"))
...
Jess is the same way.
>
> And this will have the added benefit of working if the value of "name"
> changes (in rule1, if name changes the rule does not get evaluated again,
> only if user changes, whereas in rule2, if name changes and user is dynamic
> of course, the rule get evaluated again).
>
> So, this leads to changing a little the way I was thinking of using
> definstance, etc... (this is normal as all systems have some kind of "most
> optimum" or "most elegant" way of doing things).
>
> Instead of having one object per user session that is definstanced, I think
> I will end up having most of my objects that are relevant to the rule engine
> definstanced, and some of them (those where properties change during the
> lifetime of the object) will be dynamic.
>
> Ok, so would it be a correct way of doing things to do the definstance in
> the constructor of those classes and undefinstance in the finalize of those
> classes? Obviously this would assume that the constructor of those
> particular classes have the necessary parameters to avoid having some
> important properties as null upond definstance.
>
> Is this the correct direction?
Some people have done this, and it works fine. The only thing is that
this couples your Bean classes rather tightly to Jess. Some people
might have a problem with such an architecture for this reason.
---------------------------------------------------------
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]
--------------------------------------------------------------------
