yeah there is some logic to that. Certainly easier to implement ;)
I guess thinking of business rules - nulls are evil things. Even in a
database, they are evil. Many an important report is incorrect cause it is
built on a database that allows null values, and people don't understand the
ramifica
I agree with SQL. If you also want to catch null you could do
Foo(field > 3 | == null)
cheers
Steve
On 3/15/07, Michael Neale <[EMAIL PROTECTED]> 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 Fo
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
Terry,
Thank you for reporting and providing the patch.
Patch applied:
http://jira.jboss.com/jira/browse/JBRULES-737
[]s
Edson
Terry Laurenzo wrote:
The attached diff (against 3.0.5 sources) adds a condition to the
ClassFieldInspector to not analyze methods named . For some
The attached diff (against 3.0.5 sources) adds a condition to the
ClassFieldInspector to not analyze methods named . For some
reason, the Groovy compiler is outputing classes that were causing
this check to choke and throw an IllegalArgumentException because of
a method with ACC_PUBLIC ac
