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> 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> 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