Let eventClosureWrapper take functions of =>Any

[GoogleCodeExporter]

Currently the EventIncludes object provides an implicit conversion from 
functions with return type Unit to EventHandler[T]. But in some situations 
simple expressions may return a value and thus cannot directly be implicit 
converted to an EventHandler. Would it be a big thing to change the signature 
of the convertible function to ()=>Any ?

Original issue reported on code.google.com by avithan@gmail.com on 29 Dec 2012 at 6:34

[GoogleCodeExporter]

I have hit this myself as well.

i.e. 

    pv.onScroll = (ev: ScrollEvent) => if (ev.getTouchCount==0) { ... }

gives the error message

[error] /Users/asko/Hg/ScalaSim/src/UI/ZoomablePannableGroup.scala:306: type 
mismatch;
[error]  found   : scalafx.scene.input.ScrollEvent => Any
[error]  required: javafx.event.EventHandler[_ >: 
javafx.scene.input.ScrollEvent]
[error]     pv.onScroll = (ev: ScrollEvent) => if (ev.getTouchCount==0) {
[error]                                     ^

The fix is easy in 'event/EventIncludes.scala' for the six specific conversions 
(dragEventClosureWrapper...actionEventClosureWrapper) 

and for 'scene/media/MediaIncludes.scala' for two more 
('mediaMarkerEventClosureWrapper', 'mediaErrorEventClosureWrapper').

However, I am not sure of the role of the three less explicit conversions:

    implicit def eventClosureWrapper[T <: jfxe.Event](handler: => Unit) = new 
    implicit def eventClosureWrapperWithUnitParam[T <: jfxe.Event](handler: Unit => Unit) =
    implicit def eventClosureWrapperWithParam[T <: jfxe.Event](handler: (T) => Unit) =

Probably also these should be changed?

Original comment by akau...@gmail.com on 21 Jan 2013 at 9:57

[GoogleCodeExporter]

It could be considered better practice to let the compiler complain about 
incorrect type for the function instead of silently swallowing the result the 
handler function was returning.

I see it as a mere coding exercise not to let my function return anything.

I would vote for a WontFix status on this issue.

Original comment by Alain.Fa...@gmail.com on 29 Jan 2013 at 10:48

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Its a tradeoff between usability and strictness. There are plenty 
side-effecting methods in scala that return a value. Most common usecase would 
be appending to a buffer like:
val a:AScalaFxComponent
val b:ListBuffer[String]
a.onAction = b+="pew pew"

Looks intuive and nice? Doesnt work because b+= returns itself for fluent 
usage! Just because the implicit converter expects a return type that he doesnt 
care for anyway. See this from an OO point of view. Why narrow the argument 
type of the converter if there is no need to?

Original comment by avithan@gmail.com on 30 Jan 2013 at 7:47

[GoogleCodeExporter]

I was originally of Alain's opinion. But the 'bare if' approach I show above is 
practical, otherwise frequently used in Scala (I think) and one cannot "fix" it 
by placing curly braces around the if (actually, I don't know how to neatly fix 
it).

So that's why I am a proponent of => Any in the prototypes.

Comparisons to existing similar cases within the Scala built-in libraries would 
naturally serve as a measurement stick. Imho ScalaFX should be as "built in" 
Scala as it can (i.e. Lift is not, and it shows).

Original comment by bmdesign...@gmail.com on 30 Jan 2013 at 7:57

[GoogleCodeExporter]

fixed by commit
http://code.google.com/p/scalafx/source/detail?r=00e71d72add867a43b74a58d35d5d13
b5a041b85

the whole event handling code might require a revision to reduce it to less code

Original comment by Alain.Fa...@gmail.com on 19 Feb 2013 at 1:07

• Changed state: Fixed