problems with Java

[John W. Kennedy]

It makes perfect sense. SQL embodies a consistent 3-valued logic, with
NULL as the cognate for UNKNOWN. (UNKNOWN = UNKNOWN) must be UNKNOWN.
(UNKNOWN = x) must be UNKNOWN. (UNKNOWN AND x) must be UNKNOWN.
(UNKNOWN OR x) must be UNKNOWN. (where x is one of {FALSE, TRUE, UNKNOWN})

???? In the usual 3-valued logic, UNKNOWN AND FALSE is FALSE and
UNKNOWN OR TRUE is TRUE.


--
John W. Kennedy
"Those in the seat of power oft forget their failings and seek only the
obeisance of others! Thus is bad government born! Hold in your heart
that you and the people are one, human beings all, and good government
shall arise of its own accord! Such is the path of virtue!"
-- Kazuo Koike. "Lone Wolf and Cub: Thirteen Strings" (tr. Dana Lewis)
* TagZilla 0.066 * http://tagzilla.mozdev.org

 

[Lew]

???? In the usual 3-valued logic, UNKNOWN AND FALSE is FALSE and
UNKNOWN OR TRUE is TRUE.

Oops! :-(

Yes, you're right.

 

[Guest]

Oops! :-(

Yes, you're right.

My original point was just that X=X is not always true.

Arne

 

[Chris Uppal]

All Java variables that point to objects are references, which in turn are
passed by value to methods. Objects live on the heap, never on the stack.
Objects /per se/ are never passed as method parameters.

I think "ender"s point was that this aspect of Java's semantics is unecessarily
restrictive. I.e. that there should be value objects which are used /as/
values, and therefore don't have an existance independent of "references" to
them. (They /could/ be implemented as heap objects, with only references
appearing on the stack, but doing so would obviate the main practical benefit
of such user-defined values.)

Obvious applications of such a concept include complex numbers and
(low-dimensional) points.

-- chris

 

[Oliver Wong]

As it is now, "x == y" evaluates to
true if variables x and y are equal, and this is true no matter
whether x and y are primitives or references.

Wrong. It evaluates to true if they are the same value or reference.
If
they're different objects in memory, but are equal(), == returns false.

If the reference known as "x" points to one object in memory, and the
reference known as "y" points to a different object in memory, then in my
mind, "x" and "y" are not equal. Some method invocations on those objects
(e.g. ".equals()") may return true, but that has nothing to do with the
value of the "x" reference and the "y" reference themselves.

The question is, are you trying to compare references, or are you
trying to compare objects? These are two distinct tasks.

- Oliver

 

[Lee Fesperman]

It makes perfect sense. SQL embodies a consistent 3-valued logic, with NULL as
the cognate for UNKNOWN. (UNKNOWN = UNKNOWN) must be UNKNOWN. (UNKNOWN = x)
must be UNKNOWN. (UNKNOWN AND x) must be UNKNOWN. (UNKNOWN OR x) must be
UNKNOWN. (where x is one of {FALSE, TRUE, UNKNOWN})

(The SQL standard apparently permits use of the literal UNKNOWN as a synonym
for NULL.)

UNKNOWN is not a synonym for NULL in SQL. UNKNOWN is a truth value
produced when a predicate expression contains a NULL.

 

[Lew]

UNKNOWN is not a synonym for NULL in SQL. UNKNOWN is a truth value
produced when a predicate expression contains a NULL.

OK, but

From Wikipedia

In SQL:2003 NULL is a special marker used to indicate that a data value is unknown.

NULL functions as UNKNOWN in SQL's 3-valued logic, which was my main point.

 

[Lee Fesperman]

From Wikipedia

You misread the sentence. "NULL" (all uppercase) is the SQL keyword
and concept; "unknown" (all lowercase) is the general concept, not the
SQL keyword. I didn't see anything else in the entry (thanks for the
link!) that suggested otherwise.

NULL functions as UNKNOWN in SQL's 3-valued logic, which was my main point.

SQL's 3-valued logic uses TRUE, FALSE and UNKNOWN (not NULL). NULL and
UNKNOWN are not interchangeable.

 

[Lew]

SQL's 3-valued logic uses TRUE, FALSE and UNKNOWN (not NULL). NULL and
UNKNOWN are not interchangeable.

When SQL evaluates A AND B where B is NULL, what's the result?

 

[Lee Fesperman]

When SQL evaluates A AND B where B is NULL, what's the result?

In SQL:92, B must be a logical expression and cannot be NULL (there is
no 'logical' datatype.) I don't know about SQL:03

 

[Lew]

In SQL:92, B must be a logical expression and cannot be NULL (there is
no 'logical' datatype.) I don't know about SQL:03

You're right. I should've said how does SQL evaluate

SELECT * FROM foo WHERE foo.bar = 'somevalue';

or

SELECT * FROM foo WHERE foo.bar != 'somevale';

when the value of foo.bar is NULL. Would that record appear in either result set?

 

[ender]

As an additional note:

It is just as easy (if not easier) to abuse method names as it is to
abuse operator overloading. For example it isn't that difficult to
make add() subtract (though I don't think any programmer would really
abuse it to that extent.)

 

[Lee Fesperman]

... I should've said how does SQL evaluate

SELECT * FROM foo WHERE foo.bar = 'somevalue';

or

SELECT * FROM foo WHERE foo.bar != 'somevale';

when the value of foo.bar is NULL. Would that record appear in either result set?

That's a horse of a different color! A comparison expression takes two
scalar values and returns a truth value. If either operand is NULL,
the result is the UNKNOWN truth value, otherwise the result is the
TRUE/FALSE outcome of the compare.

Both queries will not return the row where foo.bar is NULL.