These were great posts - thanks guys. It's interesting that you mention databases in relation to nulls, because this is where I've historically had to deal with null Booleans and suchlike. Usually it's as you describe - the entries are nullable and therefore I need to do something different in that scenario.
I guess I have got used to that and perhaps have a bad habbit of setting objects to null to indicate some state - rather than introduce another variable, for example I might have an array of 100 integers and rather than loop through them and setting a boolean to indicate something for each, I might null any integers that were invalid, hey- presto, extra state, same number of objects... Now I can change the way I do some of that programming, but I don't think I can change the fact that some of my data will be null - in fact in my latest project I want to enable the user to enter as little as they want - but I don't want the booleans to be treated as false or numbers as 0, they are not provided and therefore should be null. I don't think anyone has suggested an ideal solution to this yet? Cheers again! Rob. On Sep 8, 7:00 pm, Casper Bang <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
