On Sep 8, 6:57 am, SpikyOrange <r...@spikyorange.co.uk> wrote:
> get over that. For me it is as confusing and dangerous as when someone
> uses an if statement in Java without curly braces. I mean, c'mon, it's
> only a couple of braces ("it's only a return statement..."), but the
> danger of maintaining that code incorrectly (by accidentally adding
> another line of code to the if block, but not realizing there's no
> braces... or by changing the last statement of a function, without
> realizing that that completely changes what gets returned...) for me
> makes the implicit return a dubious best practice.
> (source:http://www.russmiles.com/home/2009/9/8/rob-wilson-on-javafx-language.html)"
>
I personally like it now that I've gotten used to it. I think it
generates cleaner, leaner code. I leave out the "return" keyword
too. And I often rely on if statements as the last expression as well
- the type of the if statement is the type of its body.
> > 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
>
> So, that's weird! If I wanted to have the ability to make it
> nullable, I guess I would have to wrap it in my own class?! Seems like
> an overkill. Is this the right approach, since I'm sure binding
> considerations would have to be taken into account.
No, just use a java.lang.Boolean.
e.g. this won't compile:
public var foo: Boolean = null;
but this will:
public var foo: java.lang.Boolean = null;
and I think the compiler will do the right thing with autoboxing etc.
I've coded quite a bit of code in FX now and I haven't had a need for
null boolean values.
Null handling in general seems to work well. The compiler seems to
just do the right thing.
For example,
def ok = file.create();
will set "ok" to true if the file was successfully created. But if
"file" is null, it will set it to false. It will NOT throw an NPE as
it would have in Java.
This makes initialization code work really well with binds and whatnot
- even if some of the input variables are still null things just don't
crash, they just skip evaluation.
One other thing I didn't realize earlier but which has made my FX code
much cleaner is the fact that you can stick nulls in your literal
object initialization of a sequence, and they will be ignored.
Thus, let's say you want to MAYBE add a "bar" to your list of
children. You can do this:
def bar = if (createbar) Bar {} else null;
content = [foo, bar, baz]
If createbar is false, this will create a sequence in content that
contains only foo and baz.
You can do this inline in the creation syntax too:
content: [
Foo {
foo: foo
},
if (createbar) {
Bar {
bar: bar
}
} else {
null
}
Baz {
baz: baz
}
]
-- Tor
> > 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.
>
> So when binding a Boolean it gets wrapped up anyway inside a
> BooleanVariable - perhaps there's a mechanism to use this directly or
> something similar? I know in C# they have 'boolean' and
> 'nullable<t>' (or something like that).
>
> > Hope that clears things up, if not just ask again.
>
> Oh I will! Many thanks
> 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
-~----------~----~----~----~------~----~------~--~---
