I have heard of (and from) many people involved in the development of relational databases and/or the SQL standard who regret the introduction of NULL. Codd wanted it replaced with two distinct values, Date called them "a disaster". IIRC Jim Melton had some negative comments, too: http://www.se-radio.net/podcast/2009-06/episode-137-sql-jim-melton -- it has been a while that I listened to that episode.
I don't think not only beginners would think of the following two selects as equivalent, but they are not: SELECT * FROM tableX; SELECT * FROM tableX WHERE x<=5 OR x>5; And that is a very simple case. Put a few subselects and joins in a statement and NULLs get even experienced SQL developers. Pretty much all of SQL uses ternary logic, but I suspect not too many developers think that way. Even without larger expressions the lack of semantics can get you. While people tend to think it is perfectly clear why they put a NULL somewhere, it tends not to be. Did the attribute not apply to the entity? Is it missing and should be added? Is it a value that could be derived and just wasn't cached? Or has it another, more specific meaning like "undecided" for a boolean? Sometimes I suspect NULL is just a case of premature optimization where people figured it was much better to have that than to live with fully normalized data. In some cases they might have been right, but declaring it not only a standard but also the default seems a bad idea to me. Peter Jess Holle wrote: > I've always found the whole endless debate over "null" treatment that > I've seen here and elsewhere odd. > > In databases most everything is nullable unless explicitly stated > otherwise -- and there's good reason for this. There are really good > use cases for true/false/null tri-state data -- and similar use cases > with most any other data type. How does one get this in JavaFX? > > I can see that maybe one need @Nullable Boolean to tell the JavaFX > compiler that > Joshua Marinacci wrote: >> It's also important to point out that the compiler rejects null for a >> Boolean because null simply isn't a valid value for a boolean (in the >> abstract mathematical sense of 'boolean'). Booleans can be true or >> false. That's it. The compiler rejects anything else. The same for >> Numbers. The compiler tries to enforce what makes logical sense, >> since setting a boolean to null is almost always a programmer error. >> That said, since you *can* drop down to the Java there *are* ways to >> defeat the javafxc compiler protections if you really want to, but >> then you are taking your own life into your own hands. :) >> >> On Sep 7, 2009, at 7:02 PM, TorNorbye wrote: >> >> >>> I posted a comment on the blog, but I don't see it there so I may have >>> done something wrong. >>> >>> In any case, as far as I understand things (from using the language - >>> I'm not working on the compiler team) >>> >>> 1. The return type of a function, if it isn't specified explicitly >>> (either here or in the function it is overriding or by the parameter >>> type you are supplying the function to) is inferred from the last >>> statement of the function. I personally tend to specify it >>> explicitly in function declarations, especially if it's a public >>> function. I likewise tend to specify it on variables, if I (a) want to >>> use a broad type (e.g. List instead of ArrayList)_, or (b) if I don't >>> assign to it right away. >>> >>> 2. When you see :Boolean (or :Number etc) specified as a type, that >>> doesn't mean it's a java.lang.Boolean or java.lang.Number. The JavaFX >>> compiler will try to find the most efficient way to represent it -- >>> which means that it can often use a native int, float or boolean >>> primitive. (In other cases, where there is a bind involved, it may be >>> a BooleanVariable object etc). It's pretty interesting to use the >>> javap tool to see how the variables, properties, functions etc. are >>> represented as Java classes by the compiler. This would explain why >>> you can null a string but not a boolean for example. >>> >>> Hope that clears things up, if not just ask again. >>> >>> -- Tor >>> >>> On Sep 7, 2:20 pm, Rob Wilson <netp...@gmail.com> wrote: >>> >>>> Hi all, >>>> >>>> I posted last week to let you know about my first post in JavaFX, I >>>> now have a new post that's slightly more in-depth covering some >>>> language oddities from my perspective. >>>> >>>> If you're interested...http://spikyorange.blogspot.com/ >>>> >>>> Cheers, >>>> Rob. >>>> >>>> >> >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
