[rules-users] Are there second-rate fact types?

[Wolfgang Laun]

But you can do

   declare ArrayList
   @typesafe( true )
   end

which fixes the problem, if not by default :-)

Note that the subsection 4.7.2.1.2 explains things from an
implementer's point of view, which is pretty much useless, and the
wording is rather obscure.

-W



On 10/06/2014, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
> 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 at 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 at 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>