Take all paths simultaneously, a la the qubit? ;) No for language constructs that obviously wouldn't make sense which is why in C# you'll get a compile error unless you cast bool? to bool. If that cast is done on a bool? set to null, you'd get what amounts to a ClassCastException in Java. I wonder why, given the clean slate of JavaFX, this is not build into the type system rather than being handled at annotation level. But perhaps JavaFX's @Nullable is used as a mutator unlike in Java? Does this then avoid the expensive boxing issue we often face in Java?
/Casper On 9 Sep., 03:03, Joshua Marinacci <[email protected]> wrote: > while nullable booleans make sense when you are talking about data > storage I don't think they make sense in one of your general purpose > programming constructs. For example, if boolean could be null, what > does the following code mean? > > var b:Boolean = null; > var t:Boolean = false; > if(b) { > println("true");} else { > > println("false"); > if(b == t) { > println("really false"); > } > > } > > On Sep 8, 2009, at 4:35 PM, Casper Bang wrote: > > > > > Have you checked out Scala? They have several variations of Null, > > null, nil, Nothing, None and perhaps more that I am unaware of. And in > > C# there's language support for the notion of a Nullable, basically > > automatic wrapper classes in the form of something like: > > > struct Nullable<T>{ > > public bool hasValue; > > public T Value; > > } > > > This means you don't have to overload the meaning of null, makes it > > possible to use primitive types as well and a lot more efficient than > > boxing: > > > int? x = null; > > int y = null // Not allowed > > > /Casper > > > On 9 Sep., 00:21, Rob Wilson - BabyDuke JUG <[email protected]> wrote: > >> 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 -~----------~----~----~----~------~----~------~--~---
