<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Lets forget that these are nested accessors and the problems they
    bring. Lets look at what they would be if they were real relations:<br>
    <br>
    On 29/07/2011 08:55, Wolfgang Laun wrote:
    <blockquote
cite="mid:CANaj1LdXXRbewMC7r0=UVuYbwAUKGVgtAg1XqmtpavP1LzAUtQ@mail.gmail.com"
      type="cite">Whoa! See below...<br>
      <br>
      2011/7/28 Edson Tirelli <span dir="ltr">&lt;<a
          moz-do-not-send="true" href="mailto:ed.tirelli@gmail.com">ed.tirelli@gmail.com</a>&gt;</span><br>
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="border-left: 1px solid
          rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
          1ex;">
          <br>
          <div>&nbsp;&nbsp; I think we need to differentiate paradigms here. When
            using rules, contrary to imperative code, what we are doing
            is pattern matching.</div>
          <div><br>
          </div>
          <div>X( a.b.c == &lt;value&gt; )</div>
          <div><br>
          </div>
          <div>&nbsp;&nbsp; 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.</div>
        </blockquote>
        <div><br>
          (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! <br>
          <br>
          Is there no house at some address?<br>
          &nbsp;&nbsp;&nbsp; (city.street[name].house[number] == null)&nbsp; # true =&gt; no
          such house<br>
        </div>
      </div>
    </blockquote>
    $c : City()<br>
    $s : Street( city == $c, street = "name" )<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; House( number ==&nbsp; null)<br>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote
cite="mid:CANaj1LdXXRbewMC7r0=UVuYbwAUKGVgtAg1XqmtpavP1LzAUtQ@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div><br>
          This test data with false when null: Vienna/TirelliStrasse/42
          returns "false", hence there <i>is</i> such a house. But we
          don't have a Tirelli Street in Vienna (yet)!<br>
          <br>
          Confer this to Perl's<br>
          &nbsp;&nbsp;&nbsp; ! exists $city{-streets}{"Tirelli"}[42]<br>
          )<br>
          &nbsp;</div>
        <blockquote class="gmail_quote" style="border-left: 1px solid
          rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
          1ex;">
          <div> Raising a null pointer exception, IMO, brings no
            advantage at all to the table... on the contrary, makes
            writing rules more difficult.&nbsp;</div>
        </blockquote>
        <div><br>
          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? <br>
          <br>
          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.)<br>
          <br>
          I have no problem when folks want to take shortcuts and live
          la dolce vita, but<br>
          &lt;em&gt;I don't want to be led into the bog without my
          consent.&lt;/em&gt;<br>
          <br>
          So, a builder option to turn this on is allright with me.<br>
          <br>
        </div>
        <blockquote class="gmail_quote" style="border-left: 1px solid
          rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
          1ex;">
          <div><br>
          </div>
          <div>&nbsp;&nbsp; Another example we had in the past:</div>
          <div><br>
          </div>
          <div>class Circle implements Shape</div>
          <div>class Square implements Shape</div>
          <div><br>
          </div>
          <div>rule X</div>
          <div>when</div>
          <div>&nbsp;&nbsp; &nbsp;Circle() from $shapes</div>
          <div>...</div>
          <div><br>
          </div>
          <div>&nbsp;&nbsp; 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.</div>
        </blockquote>
        <div><br>
          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.<br>
          <br>
          -W<br>
          <br>
          &nbsp;</div>
        <blockquote class="gmail_quote" style="border-left: 1px solid
          rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
          1ex;">
          <div><br>
          </div>
          <div>&nbsp;&nbsp; So, IMO, all property navigation should be null
            pointer safe in the LHS of the rules.&nbsp;</div>
          <div><br>
          </div>
          <div>&nbsp;&nbsp; This is not what happens today, but I think it should
            be fixed.</div>
          <div><br>
          </div>
          <div>&nbsp;&nbsp; Edson</div>
          <div><br>
          </div>
          <div>&nbsp;&nbsp;</div>
          &nbsp;&nbsp;<br>
          <br>
          <div class="gmail_quote">2011/7/28 Vincent LEGENDRE <span
              dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:vincent.legendre@eurodecision.com"
                target="_blank">vincent.legendre@eurodecision.com</a>&gt;</span><br>
            <blockquote class="gmail_quote" style="border-left: 1px
              solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;
              padding-left: 1ex;">
              <div>
                <div style="font-family: Times New Roman; font-size:
                  12pt; color: rgb(0, 0, 0);">Hi all,<br>
                  <br>
                  I agree with W. : NPE should be the default, and
                  "null" cases behaviour should be planned by
                  programmers.<br>
                  But I am not sure about using a new operator in rules
                  (and do the update in Guvnor ...). <br>
                  Why not using some drools annotations on the getter
                  specifying the behaviour of an eval on a null value
                  returned by this getter ? <br>
                  And may be these annotation could be added to an
                  existing POJO via the declared type syntax (just like
                  event role in fusion) ?<br>
                  <font color="#888888"><br>
                    Vincent.<br>
                  </font></div>
              </div>
              <br>
              _______________________________________________<br>
              rules-users mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:rules-users@lists.jboss.org"
                target="_blank">rules-users@lists.jboss.org</a><br>
              <a moz-do-not-send="true"
                href="https://lists.jboss.org/mailman/listinfo/rules-users"
                target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
              <br>
            </blockquote>
          </div>
          <font color="#888888"><br>
            <br clear="all">
            <br>
            -- <br>
            &nbsp; Edson Tirelli<br>
            &nbsp; JBoss Drools Core Development<br>
            &nbsp; JBoss by Red Hat @ <a moz-do-not-send="true"
              href="http://www.jboss.com" target="_blank">www.jboss.com</a><br>
          </font><br>
          _______________________________________________<br>
          rules-users mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
          <a moz-do-not-send="true"
            href="https://lists.jboss.org/mailman/listinfo/rules-users"
            target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
          <br>
        </blockquote>
      </div>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>