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