You have a valid point. I was thinking in a more general situation where the class returned by the method may be completely unrelated to the class declared in the rule. Raising a compile time error would help preventing the user writing rules that will never match.
    Maybe we can mix both approaches by doing a compile time hierarchy analysis + runtime type matching, or, if we really want to keep it dynamic, analytics module could raise a warning at compile time, but no error would be raised by the compiler and we could do only the runtime type matching.
   I'm not aware of similar semantics in other products, so, suggestions above are things that just occurred me and may not be the best ever way to handle the situation.

   Mark, what do you think?

   []s
   Edson
  

2007/9/28, Chris Woodrow <woodrow.chris@gmail.com>:
I am a bit surprised by your answer...

Let's consider :
rule "likes french cheese1"
    when
        FrenchCheese( smell == "good" )
    then
        System.out.println("likes french cheese1");
end

rule "likes french cheese2"
    when
        $person : Person ()
        FrenchCheese( smell == "good" )  from $person.getLikes()
    then
        System.out.println("likes french cheese2");
end

These 2 rules do not behave the same way :
- First one simply does not match (with a Cheese instance inserted in WM)
- Second one throws an error (see third test in my original mail)


Chris


2007/9/27, Edson Tirelli <tirelli@post.com>:

   Ideal IMO would be a compile time error, since getLikes() returns a Cheese instance, but as we use MVEL to resolve the expression, I'm not 100% sure we are able to cover all possible scenarios at compile time. I guess we can, but need to double check that.


   []s
   Edson

2007/9/27, Chris Woodrow < woodrow.chris@gmail.com>:
Thanks.
I was supposing so...
Do you think test 3 should throw a ClassCastException or just not match?
Chris

2007/9/27, Edson Tirelli < tirelli@post.com >:

   Yes, drools is deferring the type verification until it is needed (in your example, to check the constraint). May I ask you please to open a JIRA... I will fix that.

  []s
  Edson

2007/9/27, Chris Woodrow <woodrow.chris@gmail.com>:
I am sorry I didn't mean 'for' but 'from'.
:D

2007/9/27, Chris Woodrow < woodrow.chris@gmail.com>:
Hi,
I recently find out a few issues using for, and I wanted to share it with you. I made a simple exemple to illustrate my purpose.

My classes are (I did not represent accessors & constructors):

public class Cheese {
    protected String name;
}

public class FrenchCheese extends Cheese{
    private String smell;
}

public class Person {
    private Cheese likes;
}

Here is my rule set :

package rules

rule "likes cheese"
    when
        $person : Person ()
        Cheese(  ) from $person.getLikes()
    then
        System.out.println ("likes cheese");
end


rule "likes french cheese"
    when
        $person : Person ()
        FrenchCheese(  ) from $person.getLikes()
    then
        System.out.println ("likes french cheese");
end

First test :
        Cheese cheese = new FrenchCheese("good", "camembert");
        Person person = new Person();
        person.setLikes(cheese);

Output :
likes french cheese
likes cheese

Wich is expected...

Second test :
        Cheese cheese = new Cheese();
        Person person = new Person();
        person.setLikes(cheese);

Output :
likes french cheese
likes cheese

That's the first strange thing. As far as I am concerned, rule "likes french cheese" should not match (since a Cheese is not a FrenchCheese).

I made a change to the second rule :
rule "likes french cheese"
    when
        $person : Person ()
        FrenchCheese( smell == "good" ) from $person.getLikes()
    then
        System.out.println("likes french cheese");
end

Third test :
        Cheese cheese = new Cheese();
        Person person = new Person();
        person.setLikes(cheese);

output :
It throwed an exception : Exception in thread "main" java.lang.ClassCastException: rules.Cheese
I am not saying the ClassCastException is not to expect in such a case but I think I would simply expect it not to match (as far as a Cheese is not a FrenchCheese).

Chris


_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users




--
  Edson Tirelli
  Software Engineer - JBoss Rules Core Developer
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users



_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users




--
  Edson Tirelli
  Software Engineer - JBoss Rules Core Developer
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat @ www.jboss.com

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users



_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users




--
  Edson Tirelli
  Software Engineer - JBoss Rules Core Developer
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat @ www.jboss.com