We handle it as it can't be anything else but null cause null is
returned when an access fails or some error occurs. This keeps it from
falling into a valid evaluation and possibly a subtle bug going
uncaught.
 
Tom G

________________________________

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Proctor
Sent: Thursday, March 15, 2007 12:42 PM
To: Rules Dev List
Subject: Re: [rules-dev] need advice re null handling


Its not about giving it up, its how we handle when those fields are
null, do we treat it like a primitive and assume its 0, or do we say it
can't be equal to anything else but null.

In the following example neither y or z is defined, thus y is null and z
is 0;

int x = 0;
Integer y;
in z;
x == y // is false;
x == z // is true
y == null // is true

Mark

Tom Gonzalez wrote: 

        The flexibility provided by an Object is very valuable. We use
Integer and String objects all over the place today in our facts with
drools. I would hate to give it up.
         
        Tom G

________________________________

        From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Proctor
        Sent: Thursday, March 15, 2007 6:29 AM
        To: Rules Dev List
        Subject: Re: [rules-dev] need advice re null handling
        
        
        if bar is an integer it will be 0, if its an Integer it will be
null. The Q is do we make Integer work like the primitive, or do we make
it work like an Object.
        
        Mark
        Michael Neale wrote: 

                http://jira.jboss.com/jira/browse/JBRULES-627
                
                OK, this much is clear: 
                
                Foo(field == null) can be true if field is null.
                
                but, what about Foo(field > 3), and field is null?
should that be false? what about Foo(field != 3) - should that be true? 
                
                in SQL, null will always result in a false condition,
unless you explicitly use null.
                
                Thoughts? 
                
                Michael.
                
                
________________________________


                _______________________________________________
                rules-dev mailing list
                [email protected]
                https://lists.jboss.org/mailman/listinfo/rules-dev
                  


        
________________________________


        _______________________________________________
        rules-dev mailing list
        [email protected]
        https://lists.jboss.org/mailman/listinfo/rules-dev
          


_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev

Reply via email to