Hi Tor,
> I posted a comment on the blog, but I don't see it there so I may have
> done something wrong.
Many thanks for your comments, I've added a link back to this forum
post for now - it might have been intermitted because someone else
managed to post a comment.
> 1. The return type of a function
>From a safety perspective, I think I will specify the return type
explicitly - but it worries me that I'm thinking too much with my
'Java' hat on and should ride the JavaFX wave! Although it seems
professional software developers don't like it... "As I said, I'm not
exactly keen on this type of implicit return, however it is becoming
idiomatic of dynamically typed languages, so maybe I'll just have to
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)"
> 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.
> 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
-~----------~----~----~----~------~----~------~--~---
