I'm not sure what you mean. There are no annotations in JavaFX. The language tries to prevent you from doing bad things, like nulling a boolean. Preventing errors beforehand is one of the core philosophies of JavaFX Script.
- Josh On Sep 8, 2009, at 7:04 PM, Casper Bang 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 -~----------~----~----~----~------~----~------~--~---
