JESS: [EXTERNAL] No cast needed when inspecting shadow facts' data members?

2013-05-10 Thread Henrique Lopes Cardoso
Hi,

I've just noticed an interesting behavior of Jess.
I was working with a couple of classes like this:

public class X {
Object obj;
// getter and setter for obj
...
}

public class Y {
int i;
// getter and setter for i
...
}

Then in Jess I wrote:

(deftemplate X (declare (from-class X)))
(deftemplate a (slot s))

(defrule r
(X (obj ?o))
(test (eq ((?o getClass) getSimpleName) Y))
(a (s ?o.i))
=
(printout t ?o.i crlf))

(bind ?x (new X))
(bind ?y (new Y))
(?y setI 123)
(?x setObj ?y)
(add ?x)
(run)

This actually works! My surprise is related with the fact that the obj data
member is declared as an Object, and the _i_ data member only exists for
instances of Y. Despite this, the rule is able to get ?o.i in both the LHS
adn the RHS (no cast needed). Of course if I remove the test in the rule
and add to working memory an instance of X for which the obj is not an Y, I
get a runtime exception.

Is there anything I should know about the appropriateness of
implementations such as this? Best practices?

Thank you in advance.

Henrique


JESS: [EXTERNAL] Adding facts that are instances of from-class deftemplates

2013-05-10 Thread Henrique Lopes Cardoso
Hi,

I am concerned with the at least two different ways in which you can add,
to working memory, facts that are instances of from-class deftemplates.
Lets say I have:

(deftemplate FC (declare (from-class FC)))

I can add a shadow fact like this:

(bind ?fc (new FC))
(add ?fc)

This is the general approach described in Section 5.3.2 of the Jess manual.
But I can also simply go like:

(assert (FC))

I guess in this case I do not get a shadow fact, since the OBJECT slot is
nil.

So, my question is: if my facts are not supposed to be changed from Java
code, is there any difference in using each of these approaches?
Section 5.3 from the Jess manual does not even mention that instances of
from-class deftemplates can be created using the second approach above.

Thanks!

Henrique


RE: JESS: [EXTERNAL] No cast needed when inspecting shadow facts' data members?

2013-05-10 Thread Friedman-Hill, Ernest
Jess doesn't actually try to look for the I member until the code actually 
runs, so it really has no choice but to accept the code as written. This really 
isn't any different from how other dynamically typed languages behave; Java, 
being a strongly/statically typed language that would not allow this kind of 
code is actually unusual these days. Ruby, Python, Scala, Groovy, etc would all 
allow this sort of thing, no casting needed.

From: owner-jess-us...@sandia.gov [mailto:owner-jess-us...@sandia.gov] On 
Behalf Of Henrique Lopes Cardoso
Sent: Friday, May 10, 2013 9:16 AM
To: jess-users
Subject: JESS: [EXTERNAL] No cast needed when inspecting shadow facts' data 
members?

Hi,

I've just noticed an interesting behavior of Jess.
I was working with a couple of classes like this:

public class X {
Object obj;
// getter and setter for obj
...
}

public class Y {
int i;
// getter and setter for i
...
}

Then in Jess I wrote:

(deftemplate X (declare (from-class X)))
(deftemplate a (slot s))

(defrule r
(X (obj ?o))
(test (eq ((?o getClass) getSimpleName) Y))
(a (s ?o.i))
=
(printout t ?o.i crlf))

(bind ?x (new X))
(bind ?y (new Y))
(?y setI 123)
(?x setObj ?y)
(add ?x)
(run)

This actually works! My surprise is related with the fact that the obj data 
member is declared as an Object, and the _i_ data member only exists for 
instances of Y. Despite this, the rule is able to get ?o.i in both the LHS adn 
the RHS (no cast needed). Of course if I remove the test in the rule and add to 
working memory an instance of X for which the obj is not an Y, I get a runtime 
exception.

Is there anything I should know about the appropriateness of implementations 
such as this? Best practices?

Thank you in advance.

Henrique



RE: JESS: [EXTERNAL] Adding facts that are instances of from-class deftemplates

2013-05-10 Thread Friedman-Hill, Ernest
The *real* way to add shadow facts is using the definstance function. It has 
a number of options that aren't available with add. The add function was 
added to Jess to support the simplified semantics of JSR-94 (the javax.rules 
API) but the intent is that most Jess users will use definstance.

Asserting a fact directly from a from-class template is like buying a doghouse; 
you don't expect to go out the next morning and find that somehow it has a dog 
in it, right? It's certainly something you can do, but in normal life it's not 
very useful; usually you get a doghouse when you buy a dog, and add and 
definstance will both get you a doghouse for your Java object dog 
automatically.

From: owner-jess-us...@sandia.gov [mailto:owner-jess-us...@sandia.gov] On 
Behalf Of Henrique Lopes Cardoso
Sent: Friday, May 10, 2013 4:54 AM
To: jess-users
Subject: JESS: [EXTERNAL] Adding facts that are instances of from-class 
deftemplates

Hi,

I am concerned with the at least two different ways in which you can add, to 
working memory, facts that are instances of from-class deftemplates.
Lets say I have:

(deftemplate FC (declare (from-class FC)))

I can add a shadow fact like this:

(bind ?fc (new FC))
(add ?fc)

This is the general approach described in Section 5.3.2 of the Jess manual.
But I can also simply go like:

(assert (FC))

I guess in this case I do not get a shadow fact, since the OBJECT slot is nil.

So, my question is: if my facts are not supposed to be changed from Java code, 
is there any difference in using each of these approaches?
Section 5.3 from the Jess manual does not even mention that instances of 
from-class deftemplates can be created using the second approach above.

Thanks!

Henrique