Boolean is really just an Enum that can be True and False isn't it? I'm guessing a modern day version of Java would've implemented them as such. Then it would be no problem representing a tri-state, quad-state or whatever. The problem with null is that we end up with so much testing which obscures the essential parts of our code. It's actually much same debate going on in the DBMS world, with a better excuse though since this is how you denote an empty set in this relational model.
/Casper On 8 Sep., 19:13, Jess Holle <[email protected]> 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
