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
-~----------~----~----~----~------~----~------~--~---
