java.util.Collections (and descendants) are not @typesafe by default, I'll check the reason for that.

More generally, if a fact is declared as not @typesafe, the runtime failure should be more graceful.

Davide On 06/10/2014 01:26 PM, Wolfgang Laun wrote: > Consider: > > class Foo { /*...*/ } > > rule checkFoo > when > Foo( noSuchField > 0 ) > then ... end > > DRL compilation reports an error (Error: unable to resolve method ...) > and identifies rule, line and column, which is fine. > > Now let's look at: > > import java.util.ArrayList; > rule checkArrayList > when > ArrayList( noSuchField > 0 ) > then ... end > > The same DRL compiler (checked with 5.5.0 and 6.0.0) accepts this, and > there is a nasty exception thrown at runtime. This is inconvenient, > since the exception can be thrown by any code inserting an ArrayList > object, and the faulty rule isn't identified. > > Why are certain classes second-rate? > > -W > _______________________________________________ > 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

java.util.Collections (and descendants) are not @typesafe by default, I'll check the reason for that. More generally, if a fact is declared as not @typesafe, the runtime failure should be more graceful. Davide On 06/10/2014 01:26 PM, Wolfgang Laun wrote: > Consider: > > class Foo { /*...*/ } > > rule checkFoo > when > Foo( noSuchField > 0 ) > then ... end > > DRL compilation reports an error (Error: unable to resolve method ...) > and identifies rule, line and column, which is fine. > > Now let's look at: > > import java.util.ArrayList; > rule checkArrayList > when > ArrayList( noSuchField > 0 ) > then ... end > > The same DRL compiler (checked with 5.5.0 and 6.0.0) accepts this, and > there is a nasty exception thrown at runtime. This is inconvenient, > since the exception can be thrown by any code inserting an ArrayList > object, and the faulty rule isn't identified. > > Why are certain classes second-rate? > > -W > _______________________________________________ > 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

The primary concern is not so much type safety but the absence of the check of the name being defined as a getter or class member. Also, (if I understand the poster correctly) in 5.0.0 the DRL compiler was able to flag a non-existent member in ArrayList. Three cheers to not "breaking backwards compatability". Note that even when you abstain from inserting collections as first-order facts, you'll still need them, e.g., for a "from collect". -W On 10/06/2014, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: > The feature was more important when we didn't allow casting, but people > still wanted to work with Maps and Lists. > Map( this[key].age < 30) > > Collections where defaulted to typefalse(false) > > Now that we support inline casts, it can be argued that things should > always > be type safe: > Map( this[key]#Person.age < 30 ) > > It's hard to change this now, without breaking backwards compatability. > > The docs don't say that it's defaulted to false for collections, only > that > it's useful for Collections. Someone want to submit a pull request fix > for > this? > > 4.7.2.1.2. @typesafe( <boolean> ) > > By default all type declarations are compiled with type safety enabled; > @typesafe( false ) provides a means to override this behaviour by > permitting > a fall-back, to type unsafe evaluation where all constraints are > generated > as MVEL constraints and executed dynamically. This can be important when > dealing with collections that do not have any generics or mixed type > collections. > > 4.7.5. Non Typesafe Classes > > @typesafe( <boolean>) has been added to type declarations. By default all > type declarations are compiled with type safety enabled; @typesafe( false > ) > provides a means to override this behaviour by permitting a fall-back, to > type unsafe evaluation where all constraints are generated as MVEL > constraints and executed dynamically. This can be important when dealing > with collections that do not have any generics or mixed type collections. > > > Mark > > > On 10 Jun 2014, at 13:45, Davide Sottara <dsotty(a)gmail.com&gt; wrote: > >> java.util.Collections (and descendants) are not @typesafe by default, >> I'll check the reason for that. >> More generally, if a fact is declared as not @typesafe, the runtime >> failure should be more graceful. >> Davide >> >> On 06/10/2014 01:26 PM, Wolfgang Laun wrote: >>> Consider: >>> >>> class Foo { /*...*/ } >>> >>> rule checkFoo >>> when >>> Foo( noSuchField > 0 ) >>> then ... end >>> >>> DRL compilation reports an error (Error: unable to resolve method ...) >>> and identifies rule, line and column, which is fine. >>> >>> Now let's look at: >>> >>> import java.util.ArrayList; >>> rule checkArrayList >>> when >>> ArrayList( noSuchField > 0 ) >>> then ... end >>> >>> The same DRL compiler (checked with 5.5.0 and 6.0.0) accepts this, and >>> there is a nasty exception thrown at runtime. This is inconvenient, >>> since the exception can be thrown by any code inserting an ArrayList >>> object, and the faulty rule isn't identified. >>> >>> Why are certain classes second-rate? >>> >>> -W >>> _______________________________________________ >>> 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 > >