[rules-users] Condition syntax to access Map

[Edson Tirelli]

   Yes, that is exactly what I think. Pattern matching constraints are like
query parameters. They need to exist and evaluate to true in order to match.
So, for this to match:

a.b.c == null

   a needs to exist and be non-null, b needs to exist and be non-null, c
needs to exist and be null. So it is not just NP safe navigation... it is an
existence test at the same time. So for maps

a[x].b[y].c[z] == null

   The keys x, y and z need to exist, and c[z] must have a value of null.
That is what the expression above is asking for, in my understanding.

   This presents no loss of completeness to the language, as you can still
test non-existence of keys if that is what you want, but the most common
case you are looking for the opposite and it becomes much simpler to write
rules that way.

> So, a builder option to turn this on is allright with me.

   We can probably do that and have a configuration option to turn this
feature on/off.

   Edson


2011/7/29 Mark Proctor <mproctor at codehaus.org>

>  Lets forget that these are nested accessors and the problems they bring.
> Lets look at what they would be if they were real relations:
>
>
> On 29/07/2011 08:55, Wolfgang Laun wrote:
>
> Whoa! See below...
>
> 2011/7/28 Edson Tirelli <ed.tirelli at gmail.com>
>
>>
>>    I think we need to differentiate paradigms here. When using rules,
>> contrary to imperative code, what we are doing is pattern matching.
>>
>>  X( a.b.c == <value> )
>>
>>     In the above case, we are looking for Xs that make that whole
>> constraint true (i.e. match). If a or b are null, the whole expression will
>> be false, does not matter the value of c or the value it is being compared
>> against.
>>
>
> (Edson: Only if you define it so. The logical implication of c being null
> in an absent a.b (i.e., a.b==null) could very well be that "a.b.c does not
> exist", and you can't claim that a.b.c exists if a.b. doesn't!
>
> Is there no house at some address?
>     (city.street[name].house[number] == null)  # true => no such house
>
> $c : City()
> $s : Street( city == $c, street = "name" )
>        House( number ==  null)
>
> The above is identical logic to the more convenient form of nested
> accessors, it's the proper relational form. In this case if there was no
> Street, it wouldn't match.
>
>
>
>
> This test data with false when null: Vienna/TirelliStrasse/42 returns
> "false", hence there *is* such a house. But we don't have a Tirelli Street
> in Vienna (yet)!
>
> Confer this to Perl's
>     ! exists $city{-streets}{"Tirelli"}[42]
> )
>
>
>>  Raising a null pointer exception, IMO, brings no advantage at all to the
>> table... on the contrary, makes writing rules more difficult.
>>
>
> Edson, Mark,... please do recall the times where you have had an NPE in the
> code in a boolean expression? How painful would it have been if Java would
> have returned "false", continuing to cover a coding error made elsewhere?
>
> Why don't other languages tolerate "null" silently? (Perl, the most
> pragmatic of all, doesn't - it has introduced an operator I can use or not.)
>
> I have no problem when folks want to take shortcuts and live la dolce vita,
> but
> <em>I don't want to be led into the bog without my consent.</em>
>
> So, a builder option to turn this on is allright with me.
>
>
>>     Another example we had in the past:
>>
>>  class Circle implements Shape
>> class Square implements Shape
>>
>>  rule X
>> when
>>     Circle() from $shapes
>> ...
>>
>>     In the above example, $shapes is a list and the rule is clearly
>> looking for Circles. If there are Squares in there, they will just not
>> match. Raising a ClassCastException like it would happen in an imperative
>> language brings no advantage to the table, IMO.
>>
>
> This is an entirely different matter than the previous one. I see no reason
> whatsoever, not to define this "from" as working with an implicit filter.
>
> -W
>
>
>
>>
>>     So, IMO, all property navigation should be null pointer safe in the
>> LHS of the rules.
>>
>>     This is not what happens today, but I think it should be fixed.
>>
>>     Edson
>>
>>
>>
>>
>> 2011/7/28 Vincent LEGENDRE <vincent.legendre at eurodecision.com>
>>
>>>  Hi all,
>>>
>>> I agree with W. : NPE should be the default, and "null" cases behaviour
>>> should be planned by programmers.
>>> But I am not sure about using a new operator in rules (and do the update
>>> in Guvnor ...).
>>> Why not using some drools annotations on the getter specifying the
>>> behaviour of an eval on a null value returned by this getter ?
>>> And may be these annotation could be added to an existing POJO via the
>>> declared type syntax (just like event role in fusion) ?
>>>
>>> Vincent.
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>
>
> _______________________________________________
> rules-users mailing listrules-users at lists.jboss.orghttps://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
>
>


-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110729/b9e95890/attachment.html