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 -~----------~----~----~----~------~----~------~--~---
