5:39 a.m.
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
8:18 a.m.
I am sorry I didn't mean 'for' but 'from'.
:D
2007/9/27, Chris Woodrow <woodrow.chris(a)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
10:07 a.m.
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(a)gmail.com>:
I am sorry I didn't mean 'for' but 'from'.
:D
2007/9/27, Chris Woodrow <woodrow.chris(a)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(a)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
11:04 a.m.
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(a)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(a)gmail.com>:
> I am sorry I didn't mean 'for' but 'from'.
> :D
>
> 2007/9/27, Chris Woodrow < woodrow.chris(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
1:01 p.m.
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(a)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(a)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(a)gmail.com>:
>
> > I am sorry I didn't mean 'for' but 'from'.
> > :D
> >
> > 2007/9/27, Chris Woodrow < woodrow.chris(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)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
4:02 a.m.
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(a)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(a)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(a)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(a)gmail.com>:
> >
> > > I am sorry I didn't mean 'for' but 'from'.
> > > :D
> > >
> > > 2007/9/27, Chris Woodrow < woodrow.chris(a)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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
8:06 a.m.
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(a)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(a)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(a)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(a)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(a)gmail.com>:
> > >
> > > > I am sorry I didn't mean 'for' but 'from'.
> > > > :D
> > > >
> > > > 2007/9/27, Chris Woodrow < woodrow.chris(a)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(a)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(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)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
5:02 a.m.
Hi
I stumbled upon this problem last week. I see this is a very old post, and I
was wondering if a "solution" has been implemented?
It seems logical to me, that "from" only matches if an element in the list
matches the required subclass. This means the classcast exception is catched
and causes the rule not to match.
rule "likes french cheese"
when
$person : Person ()
FrenchCheese( smell == "good" ) from $person.getLikes()
then
System.out.println("likes french cheese");
end
This rule should only match FrenchCheese, even if other subclasses of Cheese
are present in the set of Cheeses (getLikes()).
They way I avoid it now is using an Enum containing each Cheese class (since
I can't get it working with reflection).
rule "likes french cheese"
when
$person : Person ()
$cheese : Cheese( cheeseType == CheeseTypes.FrenchCheese ) from
$person.getLikes()
FrenchCheese( smell == "good" ) from $cheese
then
System.out.println("likes french cheese");
end
A bit awkward in my opinion. It would be nice if drools provided for the
matching itself.
So again, has this "problem" evolved since 2007?
Greetz
Evert
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/About-for-and-inherit...
Sent from the Drools - User mailing list archive at Nabble.com.
10:10 a.m.
If smell is a property of Cheese and not just of FrenchCheese you could use
when
$person : Person ()
$c: Cheese( eval( $c instanceof FrenchCheese), smell == "good" ) from
$person.getLikes()
then
Also, I think that a selective retrieval with an overloaded version of
getLikes():
getLikes( Class clazz )
might be useful, avoiding useless elements in the returned collection.
-W
On 14 January 2011 12:02, Evert Penninckx <evert.penninckx(a)gmail.com> wrote:
Hi
I stumbled upon this problem last week. I see this is a very old post, and
I
was wondering if a "solution" has been implemented?
It seems logical to me, that "from" only matches if an element in the list
matches the required subclass. This means the classcast exception is
catched
and causes the rule not to match.
rule "likes french cheese"
when
$person : Person ()
FrenchCheese( smell == "good" ) from $person.getLikes()
then
System.out.println("likes french cheese");
end
This rule should only match FrenchCheese, even if other subclasses of
Cheese
are present in the set of Cheeses (getLikes()).
They way I avoid it now is using an Enum containing each Cheese class
(since
I can't get it working with reflection).
rule "likes french cheese"
when
$person : Person ()
$cheese : Cheese( cheeseType == CheeseTypes.FrenchCheese ) from
$person.getLikes()
FrenchCheese( smell == "good" ) from $cheese
then
System.out.println("likes french cheese");
end
A bit awkward in my opinion. It would be nice if drools provided for the
matching itself.
So again, has this "problem" evolved since 2007?
Greetz
Evert
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/About-for-and-inherit...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4:32 a.m.
The problem is exactly that smell is not an attribute of Cheesy (for this
Cheese example we could argue if that makes sense, but in my context it 's
impossible).
I thought I had an error from the drools plugin when using instanceof even
in eval, but I'll try that again, I think I tried eval(this instanceof ...).
In my case it would still mean writing something like
when
$person : Person ()
$cheese : Cheese( eval( $cheese instanceof FrenchCheese) ) from
$person.getLikes()
FrenchCheese( smell == "good" ) from $cheese
Overloading getLikes() would be more elegant. Still, for me these are
workarounds.
Would it be that strange or unconventional to have the from only match on
the required subclass?
Grtz
Evert
Wolfgang Laun-2 wrote:
If smell is a property of Cheese and not just of FrenchCheese you could
use
when
$person : Person ()
$c: Cheese( eval( $c instanceof FrenchCheese), smell == "good" )
from
$person.getLikes()
then
Also, I think that a selective retrieval with an overloaded version of
getLikes():
getLikes( Class clazz )
might be useful, avoiding useless elements in the returned collection.
-W
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/About-for-and-inherit...
Sent from the Drools - User mailing list archive at Nabble.com.
7:24 a.m.
On 15 January 2011 11:32, Evert Penninckx <evert.penninckx(a)gmail.com> wrote:
I thought I had an error from the drools plugin when using instanceof even
in eval, but I'll try that again, I think I tried eval(this instanceof
...).
You cannot use this in an eval. The eval is "moved out" from the containing
pattern,
and there this has no meaning.
Overloading getLikes() would be more elegant. Still, for me these are
workarounds.
Would it be that strange or unconventional to have the from only match on
the required subclass?
Given that getLikes() is *your *choice of method producing the data, and
that
FrenchCheese is *your *choice of type for the receiver: would it be that
strange
or unconventional to expect you to employ matching types? ;-)
Type checking should not result in the silent elimination of data at
runtime. What
I would expect Drools to tell me is the incompatibility of the from and the
receiving
pattern, at compile time.
-W
Grtz
Evert
Wolfgang Laun-2 wrote:
>
> If smell is a property of Cheese and not just of FrenchCheese you could
> use
>
>
> when
> $person : Person ()
> $c: Cheese( eval( $c instanceof FrenchCheese), smell == "good" )
> from
> $person.getLikes()
> then
>
> Also, I think that a selective retrieval with an overloaded version of
> getLikes():
> getLikes( Class clazz )
> might be useful, avoiding useless elements in the returned collection.
>
> -W
>
>
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/About-for-and-inherit...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5046
days inactive
6252
days old
10 comments
4 participants
participants (4)
-
Chris Woodrow -
Edson Tirelli -
Evert Penninckx -
Wolfgang Laun