Um, unless I'm mistaken, there are no annotations in JavaFX. Unless its undocumented, in the (as yet incomplete after nearly 12 months) language reference.
http://openjfx.java.sun.com/current-build/doc/reference/JavaFXReference.html On Sep 9, 12:04 pm, Casper Bang <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
