Hi Jevon, That is a discussion we had for some time (whether "from" should check return type or not for matching purposes). The only reason it was not implemented so far is that it would possibly cause "silent failures". Example: Person( name == "bob" ) from $people If $people returns an Alien() and the check is in place, the rule will not match and the user might not notice the reason, as the way it is today, it will raise a ClassCastException. Although, in my opinion, the advantages of the check surpass the "silent failure" problem and we should add this check, specially because sometimes you have a collection of objects that share a common superclass, but with different actual subclasses instances, and you want to operate only on a give subclass. Anyway, I will talk with Mark and possibly add this to Drools 5.1. Regarding your keyword usage issue, I added a comment to it: https://jira.jboss.org/jira/browse/JBRULES-2218 Regards, Edson 2010/2/24 Jevon Wright <jevon(a)jevon.org&gt; > Hi, > > I am using Drools 4.0.7, and I had a DRL rule similar to the following: > > rule "..." > when > other : Foo( ) > x : Bar( ) from other.property > > then > ... > end > > An unexpected bug occured. In some situations, other.property would _not_ > be of type Bar, yet Drools would still think that it was. As a result I was > getting some unusual exceptions being thrown: "org.mvel.CompileException: > unable to resolve property: ..." > > If I changed the rule to: > x : Bar( ) from other.property > eval ( x instanceof Bar ) > > It would instead throw a ClassCastException (i.e. "Baz cannot be cast into > Bar"). > > If, instead, I changed the rule to: > x : Bar( other.property == x ) > > It would start working correctly, and 'x' would only be of type Bar. > > Is this known behaviour? Is it expected? If so, I would appreciate it if > the 4.0.7 documentation was updated to reflect that "from" actually ignores > the return type of properties. It took me a couple of hours to detect and > fix this bug. > > I would try these rules in Drools 5.x, but I'm still waiting for the > blocking JBRULES-2218 to be resolved. > > Cheers > Jevon > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

-----Original Message----- From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users- bounces(a)lists.jboss.org] On Behalf Of Simon Thum Sent: 03 March 2010 11:08 To: Rules Users List Subject: Re: [rules-users] "from" keyword does not actually check types? Edson Tirelli wrote: > Hi Jevon, > > That is a discussion we had for some time (whether "from" should check > return type or not for matching purposes). The only reason it was not > implemented so far is that it would possibly cause "silent failures". > Example: > > Person( name == "bob" ) from $people > > If $people returns an Alien() and the check is in place, the rule will > not match and the user might not notice the reason, as the way it is today, > it will raise a ClassCastException. > > Although, in my opinion, the advantages of the check surpass the "silent > failure" problem and we should add this check, specially because sometimes > you have a collection of objects that share a common superclass, but with > different actual subclasses instances, and you want to operate only on a > give subclass. > > Anyway, I will talk with Mark and possibly add this to Drools 5.1. FWIW, I'd appreciate both options being possible. Maybe an explicit qualification makes sense, like (subset|all)? from ... so you'd retain error checks where appropriate. > > Regarding your keyword usage issue, I added a comment to it: > > https://jira.jboss.org/jira/browse/JBRULES-2218 > > Regards, > Edson > > 2010/2/24 Jevon Wright <jevon(a)jevon.org&gt; > >> Hi, >> >> I am using Drools 4.0.7, and I had a DRL rule similar to the following: >> >> rule "..." >> when >> other : Foo( ) >> x : Bar( ) from other.property >> >> then >> ... >> end >> >> An unexpected bug occured. In some situations, other.property would _not_ >> be of type Bar, yet Drools would still think that it was. As a result I was >> getting some unusual exceptions being thrown: "org.mvel.CompileException: >> unable to resolve property: ..." >> >> If I changed the rule to: >> x : Bar( ) from other.property >> eval ( x instanceof Bar ) >> >> It would instead throw a ClassCastException (i.e. "Baz cannot be cast into >> Bar"). >> >> If, instead, I changed the rule to: >> x : Bar( other.property == x ) >> >> It would start working correctly, and 'x' would only be of type Bar. >> >> Is this known behaviour? Is it expected? If so, I would appreciate it if >> the 4.0.7 documentation was updated to reflect that "from" actually ignores >> the return type of properties. It took me a couple of hours to detect and >> fix this bug. >> >> I would try these rules in Drools 5.x, but I'm still waiting for the >> blocking JBRULES-2218 to be resolved. >> >> Cheers >> Jevon >> >> _______________________________________________ >> 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 _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users