Clumsy finger sent last e-mail too soon. To finish my last sentence....
I can see that maybe one need @Nullable Boolean to tell the JavaFX compiler that this should not be a simple "boolean", but I cannot see discarding a built in way of denoting true/false/null in one data item. 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 <[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 -~----------~----~----~----~------~----~------~--~---
