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 <netp...@gmail.com> 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 <casper.b...@gmail.com> 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 <je...@ptc.com> 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 <netp...@gmail.com> 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 javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
