ScalaFX and JavaFX 8

199 views
Skip to first unread message

Peter Pilgrim

unread,
Feb 6, 2013, 5:26:48 PM2/6/13
to scala...@googlegroups.com
Jarek and Asko

Can you both set up a branch of ScalaFx for JavaFx 8 and put code in
it please? I am not sure if this is a high priority item; I think
getting a 1.0.0 that works with Java 7 and JavaFX 2.2.x is the top
priority.

Scala 2.10 has taken a new reserved word "then"; what should be a
replacement? Can you both start the discussions on this too?

Regards

(unfortunately I cannot commit more time to ScalaFx at the mo )


Sent from my iPhone 4S

Asko Kauppi

unread,
Feb 8, 2013, 2:50:52 AM2/8/13
to scala...@googlegroups.com
Hmm... Not sure how I got to be mentioned with JavaFX 8. I'm using Java 7 and Scala 2.10 - and actually agree with Peter on the priorities.

Also, I'm starting an equity crowdfunding round on my company (do ask for more info :) ) and this will keep me out of coding for some weeks, I'm afraid (or hope). 

As to 'then', I simply quoted those words in the Scala sources as `then` and imho that would be enough to cover the issue for now.

- asko

Peter Pilgrim

unread,
Feb 8, 2013, 6:07:35 AM2/8/13
to scala...@googlegroups.com
Hi Asko

Good luck with the crowd funding.
I think this is minor issue too.
I will create an issue ticket and then park it for now.

The work around with back quotes is actually a good solution.
> --
> You received this message because you are subscribed to the Google Groups
> "ScalaFX Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scalafx-dev...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Peter Pilgrim,

Alain FAGOT BÉAREZ

unread,
Feb 8, 2013, 9:35:58 AM2/8/13
to scala...@googlegroups.com
About "then" becoming keyword, it was suggested back in July to rename our "then" method to be "use".

In the same way as we broke backward compatibility with the recent change from alignment to alignmentInParent and innerAlignment to alignment, I think we could "release early" the change from then to use and thus get ready for the next changes.

Alain

Peter Pilgrim

unread,
Feb 8, 2013, 9:49:18 AM2/8/13
to scala...@googlegroups.com
Actually,I was thinking of other synonyms too.

color <== when (hover) afterwards Color.GREEN otherwise Color.RED

color <== when (hover) next Color.GREEN otherwise Color.RED

color <== when (hover) after Color.GREEN otherwise Color.RED

color <== when (hover) select Color.GREEN otherwise Color.RED

color <== when (hover) follow Color.GREEN otherwise Color.RED

color <== when (hover) perform Color.GREEN otherwise Color.RED

color <== when (hover) define Color.GREEN otherwise Color.RED

color <== when (hover) then Color.GREEN otherwise Color.RED
> --
> You received this message because you are subscribed to the Google Groups
> "ScalaFX Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scalafx-dev...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Peter Pilgrim,
**Java Champion**,
Java EE Software Development / Design / Architect for `BlueChip'
enterprises, London, UK

JavaFX ++ Scala ++ Groovy ++ Android ++ Java

:: http://www.xenonique.co.uk/blog/ ::
:: http://twitter.com/peter_pilgrim ::
:: http://audio.fm/profile/peter_pilgrim ::
:: Skype Call peter_pilgrim ::
:: http://java-champions.java.net/ ::

Matthew Pocock

unread,
Feb 8, 2013, 10:22:15 AM2/8/13
to scala...@googlegroups.com
When you lay it out like that, it's a pity we can't rebind the if/then/else syntax directly:

color <== if(hover) then Color.GREEN else Color.RED

Is this worth bounding to the scala list? The type of `hover` is clearly not a boolean, so there's an obvious way to know that the syntax is being re-bound. I really don't like the synonyms that look temporal e.g. afterwards, next, after. The `select` `otherwise` pair read nicest to me.

Matthew
Dr Matthew Pocock
Integrative Bioinformatics Group, School of Computing Science, Newcastle University
skype: matthew.pocock
tel: (0191) 2566550

Matthew Pocock

unread,
Feb 8, 2013, 9:41:06 AM2/8/13
to scala...@googlegroups.com
My advice is to break compatibility now, while you don't have 100,000 users and avoid the next wave of adopters either having to struggle with avoidable ugliness or later breaking compatibility when there are lots of existing applications, blogs and tutorials and a book.If 'then' must be addressed at some time, let's address it now.

Matthew

On 8 February 2013 14:35, Alain FAGOT BÉAREZ <a...@cua.li> wrote:

--
You received this message because you are subscribed to the Google Groups "ScalaFX Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalafx-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--

Jarek Sacha

unread,
Feb 8, 2013, 3:10:35 PM2/8/13
to scala...@googlegroups.com, Matthew Pocock, Alain FAGOT BÉAREZ
Both
    when condition use value1 otherwise value2
and
    when condition select value1 otherwise value2
sound fine to me.

Jarek

Asko Kauppi

unread,
Feb 10, 2013, 9:00:10 AM2/10/13
to scala...@googlegroups.com, Matthew Pocock, Alain FAGOT BÉAREZ

Disclaimer: I'm not seriously advocating changes to the Scala language, to cater for this. But...


That would allow:

color <== if (hover) Color.GREEN else Color.RED 

Maybe that's even a bit misleading. But nice. Personally, I'm okay simply by a functional 'bind' mechanism. Having too much of sugar in libraries is normally more harm than useful. And you can never take it out, once it's there (or someone cries).

-asko

Rafael Afonso

unread,
Feb 11, 2013, 7:52:06 AM2/11/13
to scala...@googlegroups.com, Matthew Pocock, Alain FAGOT BÉAREZ
Personally, I prefer use because select sounds too much SQL for me :/.
IMHO, a way to proceed the transition from then to use (or whatever the name we adopt) is first copy then body to this successor. After, then is declared as deprecated while calls its respective successor. For example, in Bindings trait we have:

def then(thenExpression: Int) = new NumberConditionBuilder(whenBuilder.then(thenExpression))

we could rewrite thia as below:
  
 /**
  * Defines a constant value of the ternary expression, that is returned if the condition is true. `use` name is used to not conflict with Scala 2.10 `then` keyword.
   */
def use(thenExpression: Int) = new NumberConditionBuilder(whenBuilder.then(thenExpression))
@depretated("Use 'use' instead")
def then(thenExpression: Int) = use(thenExpression)

then method in whenBuilder comes from When class in javafx.beans.binding package. Therefore, when we convert to Scala 2.10 version, we should add a ` around then:

 /**
  * Defines a constant value of the ternary expression, that is returned if the condition is true. `use` name is used to not conflict with Scala 2.10 `then` keyword.
   */
def use(thenExpression: Int) = new NumberConditionBuilder(whenBuilder.`then`(thenExpression))

the same applies to other versions of then.

Thanks, 

Rafael Afonso

Jarek Sacha

unread,
Feb 11, 2013, 9:28:44 PM2/11/13
to scala...@googlegroups.com
I think Rafael deprecation idea is good. This will give some transition period for those that may be using `when/then/otherwise`. Let deprecate it in Milestone 1, and remove `then` in Milestone 3 (not sure how many we will have), so we will have "clean" milestone before 1.0 release.

We still need to make choice between `use` and `select`. I do not have a strong preference, but if had to choose right now, I would go with `select`, sounds a bit better in context of making a binary decision (`when`).

My plane is to complete Milestone 1 on Friday (Feb. 15). I hope we can pick replacement for `then` by Thursday, tentatively assuming `select`.

Jarek


On 2/11/2013 7:52 AM, Rafael Afonso wrote:

Peter Pilgrim

unread,
Feb 12, 2013, 5:39:10 AM2/12/13
to scala...@googlegroups.com
Hi Jarek and Rafeal

I prefer the "select" as well.
However I made a quick check on Slick http://slick.typesafe.com/ to
make sure it is not used there.
In the first couple examples I did not see it.
It might be worth checking out other Scala DSL frameworks and asking
around just to make sure we do not get a conflict.

Good job both of you so far.

Matthew Pocock

unread,
Feb 12, 2013, 8:27:20 AM2/12/13
to Rafael Afonso, scala...@googlegroups.com, Alain FAGOT BÉAREZ
On 11 February 2013 12:52, Rafael Afonso <rafael...@gmail.com> wrote:
 /**
  * Defines a constant value of the ternary expression, that is returned if the condition is true. `use` name is used to not conflict with Scala 2.10 `then` keyword.
   */
def use(thenExpression: Int) = new NumberConditionBuilder(whenBuilder.then(thenExpression))
@depretated("Use 'use' instead")
def then(thenExpression: Int) = use(thenExpression)

Just a coding-style note, but I think with the upcoming compiler optimizations, we can do something like this:

@deprecated("Use 'use' instead") @inline
final def then(thenExpression: Int) = use(thenExpression) 

Fingers crossed, when the new compiler magic hits, this will ensure that all uses of `then` in source get optimized away and replaced with calls to `use`. In future, if we where to remove this method, optimized code would continue to work 'out of the box', as classfiles of code compiled against this wouldn't know anything about `then`, as it would have always been inlined away. The important thing is to mark it as @inline and final.

Sorry for the noise, it was just something that occurred to me.

Matthew

Matthew Pocock

unread,
Feb 12, 2013, 8:26:47 AM2/12/13
to Rafael Afonso, scala...@googlegroups.com, Alain FAGOT BÉAREZ
On 11 February 2013 12:52, Rafael Afonso <rafael...@gmail.com> wrote:
 /**
  * Defines a constant value of the ternary expression, that is returned if the condition is true. `use` name is used to not conflict with Scala 2.10 `then` keyword.
   */
def use(thenExpression: Int) = new NumberConditionBuilder(whenBuilder.then(thenExpression))
@depretated("Use 'use' instead")
def then(thenExpression: Int) = use(thenExpression)

Just a coding-style note, but I think with the upcoming compiler optimizations, we can do something like this:

@deprecated("Use 'use' instead") @inline
final def then(thenExpression: Int) = use(thenExpression) 

Fingers crossed, when the new compiler magic hits, this will ensure that all uses of `then` in source get optimized away and replaced with calls to `use`. In future, if we where to remove this method, optimized code would continue to work 'out of the box', as classfiles of code compiled against this wouldn't know anything about `then`, as it would have always been inlined away. The important thing is to mark it as @inline and final.

Sorry for the noise, it was just something that occurred to me. It may not be relevant until/unless the compiler enhancements are back-ported to 2.10.*, or we all upgrade to 2.11.

Matthew

Alain FAGOT BÉAREZ

unread,
Feb 14, 2013, 10:09:01 AM2/14/13
to scala...@googlegroups.com
Em terça-feira, 12 de fevereiro de 2013 07h39min10s UTC-3, Peter Pilgrim escreveu:
I prefer the "select" as well.
However I made a quick check on Slick http://slick.typesafe.com/ to
make sure it is not used there.

"select" is used in Squeryl, jOOQ and QueryDSL though I don't know how much "main stream" these projects are.

I would stick with "use" for it is quite tasteless enough.

Alain

Peter Pilgrim

unread,
Feb 14, 2013, 10:38:22 AM2/14/13
to scala...@googlegroups.com
I was forgetting that in Scala you also import packages to scope. The
closer the import is the true scope; the higher the precedence

import squeryl._

{
val x = select X of B
{
import scalafx.control._
val button = Button { ... }
button.fill = when ( button.hover ) select RED otherwise BLUE
}
}

Or something like that; so I believe my original concern is misplaced.

Rafael Afonso

unread,
Feb 14, 2013, 11:08:45 AM2/14/13
to scala...@googlegroups.com
Why don't we create a form in Google Drive to query users and developers what they prefer?

Jarek Sacha

unread,
Feb 14, 2013, 10:29:29 PM2/14/13
to scala...@googlegroups.com
On 2/14/2013 11:08 AM, Rafael Afonso wrote:
Why don't we create a form in Google Drive to query users and developers what they prefer?
I think we should be making API decisions within the developer community. We are discussing this for quite a while. By now anybody who wanted to voice their decision had the time to do it.
 
To sum up. Scala 2.10 "then" is a reserve word. Its use as an identifier is deprecated. This in turn requires replacement of "then" in binding constructs like:
    fill <== when(hover) then Color.GREEN otherwise Color.RED

"then" is actually a set of methods of class ConditionBuilder, so there is probably no chance for clash with other DSLs (method is invoked on an object, it is not a stand alone construct).

To tally the votes: there are two supporters of "use" (Alain, Rafael) and two supporters of "select" (Peter, Matthew). I have a slight preference for "select", so we can count 2 to 3 at this point (let me know if I not missing something here). If we run into some issues or get some strong opinions other way we can still change it before final release of 1.0. I will wait one more day, till the end of day Friday, if somebody wants to change their mind. I would like to on Saturday change "then" to its successor and stage Milestone 1 with a day or two testing of downloads. The Milestone 1 release will be both for Scala 2.9.2 and 2.10.

Jarek

Alain FAGOT BÉAREZ

unread,
Feb 16, 2013, 5:52:24 AM2/16/13
to scala...@googlegroups.com
Em sexta-feira, 15 de fevereiro de 2013 00h29min29s UTC-3, Jarek escreveu:
To sum up. Scala 2.10 "then" is a reserve word. Its use as an identifier is deprecated. This in turn requires replacement of "then" in binding constructs like:
    fill <== when(hover) then Color.GREEN otherwise Color.RED

"then" is actually a set of methods of class ConditionBuilder, so there is probably no chance for clash with other DSLs (method is invoked on an object, it is not a stand alone construct).

Maybe to shed more confusion about the choice for the `then` replacement, I remembered yesterday that XSLT has a choose-when-otherwise construct which could be remembered by some developpers (though it has been so much time without XML in my daily work):
fill <== when(hover) choose Color.GREEN otherwise Color.RED

Regards,
Alain

Matthew Pocock

unread,
Feb 16, 2013, 7:49:50 AM2/16/13
to scala...@googlegroups.com
On 15 February 2013 03:29, Jarek Sacha <jps...@gmail.com> wrote:
On 2/14/2013 11:08 AM, Rafael Afonso wrote:
Why don't we create a form in Google Drive to query users and developers what they prefer?
I think we should be making API decisions within the developer community. We are discussing this for quite a while. By now anybody who wanted to voice their decision had the time to do it.
 
To tally the votes: there are two supporters of "use" (Alain, Rafael) and two supporters of "select" (Peter, Matthew). I have a slight preference for "select", so we can count 2 to 3 at this point (let me know if I not missing something here).

If it's OK, having ruminated on this for a week, I have a slight preference for 'use'. However, any of 'use', 'select' and 'choose' are fine by me.
 
Matthew

If we run into some issues or get some strong opinions other way we can still change it before final release of 1.0. I will wait one more day, till the end of day Friday, if somebody wants to change their mind. I would like to on Saturday change "then" to its successor and stage Milestone 1 with a day or two testing of downloads. The Milestone 1 release will be both for Scala 2.9.2 and 2.10.

Jarek

--
You received this message because you are subscribed to the Google Groups "ScalaFX Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalafx-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--

Rafael Afonso

unread,
Feb 16, 2013, 10:21:58 AM2/16/13
to scala...@googlegroups.com
+1

Jarek Sacha

unread,
Feb 16, 2013, 12:27:58 PM2/16/13
to scala...@googlegroups.com, Rafael Afonso, Matthew Pocock, Peter Pilgrim, Alain FAGOT BÉAREZ
Current preference, if I interpret email correctly, is:

select - 2 : Jarek, Peter
use - 2 : Matthew, Rafael
choose - 1 - Alain

Though I am not completely certain about Alain.

Alain, can you confirm that you now prefer 'choose'? Otherwise we can agree 'use'.

Jarek

Alain FAGOT BÉAREZ

unread,
Feb 18, 2013, 8:58:59 AM2/18/13
to scala...@googlegroups.com
Em sábado, 16 de fevereiro de 2013 14h27min58s UTC-3, Jarek escreveu:
Current preference, if I interpret email correctly, is:

select - 2 : Jarek, Peter
use - 2 : Matthew, Rafael
choose - 1 - Alain

Alain, can you confirm that you now prefer 'choose'? Otherwise we can agree 'use'.

My preference goes as following:
- select ==> strong rejection
- use ==> acceptable alternative
- choose ==> preferred option

What about the opinion from the other 15 registered committers?

Best regards,
Alain

Sven Reimers

unread,
Feb 18, 2013, 9:52:20 AM2/18/13
to scala...@googlegroups.com

Choose  +1

-Sven

--

rajma...@gmail.com

unread,
Feb 18, 2013, 10:31:30 AM2/18/13
to scala...@googlegroups.com
choose ==> ++1
--
Thank you and regards,
Rajmahendra R Hegde (Raj)
Website:
http://www.twitter.com/rajonjava
http://www.jugchennai.in             
----------------------------------------------------------------------------------------------
"DREAM is not what you see in sleep;
is the thing which does not let you sleep" - APJ Abdul Kalam
Do the difficult things while they are easy and do the great things while they are small.
A journey of a thousand miles must begin with a single step. - Lao Tzu


Jarek Sacha

unread,
Feb 18, 2013, 10:12:16 AM2/18/13
to scala...@googlegroups.com
I am fine with ‘choose’ too, if that will help to move things along :)

Jarek


On 2/18/2013 9:52 AM, Sven Reimers wrote:

Stephen Chin

unread,
Feb 18, 2013, 5:35:59 PM2/18/13
to scala...@googlegroups.com, scala...@googlegroups.com
+1 for choose from me as well.

Cheers,
--Steve

Jarek Sacha

unread,
Feb 19, 2013, 10:47:50 PM2/19/13
to scala...@googlegroups.com
Looks that we have a winner:

choose : 5 votes 
use : 2
select : 

I will mark `then` as deprecated with intention to remove by Milestone 3. `choose` will be used instead.

Peter Pilgrim

unread,
Feb 20, 2013, 11:30:27 AM2/20/13
to scala...@googlegroups.com
Hi All

Great! We have an unanimous decision. Let us implement "choose".

On 20 February 2013 03:47, Jarek Sacha <jps...@gmail.com> wrote:
> Looks that we have a winner:
>
> choose : 5 votes
> use : 2
> select : 1
>

--
Peter Pilgrim,
Reply all
Reply to author
Forward
0 new messages