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 <mproc...@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 <dso...@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@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
>
>
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
