https://kotlinlang.org logo
Channels
Powered by
#tornadofx
  • e

    edvin

    11/02/2016, 4:53 PM
    This is how I envision us documenting each sample in the kitchen sink. I'm sure this will be valuable to people trying to understand the samples.
    👍 3
  • c

    carlw

    11/02/2016, 5:01 PM
    @edvin have you seen the FXDocs project?
  • e

    edvin

    11/02/2016, 5:14 PM
    I just created 
    UIComponet.openWindow()
    which is like 
    openModal()
    but modeless by default
  • e

    edvin

    11/02/2016, 5:15 PM
    @carlw Yes I have 🙂
  • e

    edvin

    11/02/2016, 5:31 PM
    My first screencast will be showing the ItemViewModel in combination with Scope, based on that first kitchensink sample. It'll be out in a few hours 🙂
    👍 2
  • c

    carlw

    11/02/2016, 5:31 PM
    great. i like the markdown format of the README
  • e

    edvin

    11/02/2016, 5:32 PM
    Me too. I love that it supports the K syntax fairly well for code samples also. Generally very little markup is needed to write documentation that way.
  • h

    hastebrot

    11/02/2016, 6:07 PM
    what do you guys think about functions with lots of parameters having default values?
  • e

    edvin

    11/02/2016, 6:09 PM
    @hastebrot Generally I would prefer that function to take some kind of parameter object with those default values, but we actually do exactly what you say in TornadoFX. It has proven quite OK to evolve those functions with more parameters as well, as long as they are added at the end.
  • e

    edvin

    11/02/2016, 6:10 PM
    fun openWindow(stageStyle: StageStyle = StageStyle.DECORATED, modality: Modality = Modality.NONE, escapeClosesWindow: Boolean = true, owner: Window? = null, block: Boolean = false)
  • h

    hastebrot

    11/02/2016, 6:10 PM
    I think these functions are similar to unix commands that take arguments, or functions in JavaScript that take configuration objects.
  • e

    edvin

    11/02/2016, 6:10 PM
    You're right. I think the default parameter value support makes this a pretty natural thing to do in Kotlin.
    K 1
  • h

    hastebrot

    11/02/2016, 6:11 PM
    my intended use was for functions like 
    setupPrimaryStage()
    and 
    lookupNodes()
    .
  • e

    edvin

    11/02/2016, 6:11 PM
    Discoverability of the default values are also much higher than with a configuration object.
  • e

    edvin

    11/02/2016, 6:12 PM
    They are prime candidates IMO.
  • e

    edvin

    11/02/2016, 6:13 PM
    (I'm itching to create a screencast, but a worker is living in my home office and there are too many people around on the ground floor to make a screencast right now.. grrr)
  • t

    thomasnield

    11/02/2016, 6:14 PM
    @edvin @hastebrot Remember the [builder Pattern in Java](http://stackoverflow.com/a/1953567/1373258). As great as it seemed initially, I think we can all agree configuration objects like that add enormous amounts of boilerplate...
  • h

    hastebrot

    11/02/2016, 6:14 PM
    setupPrimaryStage()
    is for me the culmination of best practices to setup JavaFX test fixtures.
  • e

    edvin

    11/02/2016, 6:15 PM
    @thomasnield Agreed. Builders also have a troubling track record in Java projects for some reason. They were actually removed/deprecated from JavaFX because of some technical issue AFAIK.
  • e

    edvin

    11/02/2016, 6:16 PM
    @hastebrot Nice. I'd be interested to see what default values you choose.
  • t

    thomasnield

    11/02/2016, 6:16 PM
    I remember that too. I used them heavily before I switched to Kotlin, but the alternative would be creating enormous amounts of overload methods.
  • t

    thomasnield

    11/02/2016, 6:16 PM
    Anyway, named parameters are awesome, even if there are dozens of them
    👍 1
  • e

    edvin

    11/02/2016, 6:17 PM
    I tried to use Lombok for builders, but ran into problems with JPA etc.
  • h

    hastebrot

    11/02/2016, 6:21 PM
    Probably (without testing it): 
    setupPrimaryStage(timeoutMillis: Long = 0, startupFunction: () -> Unit =  { PlatformImpl.startup() }, primaryStageProvider: () -> Stage = { PRIMARY_STAGE }, action: () -> Unit = {})
  • h

    hastebrot

    11/02/2016, 6:25 PM
    Default value for 
    timeout
    is defined using a static 
    setTimeoutMillis()
    method in TestFX. This is important for test runs not to hang. A parameter for 
    startupFunction
    is needed to make the function testable (for internal test suite), 
    primaryStageProvider
    to make the primaryStage configurable, (re)using a single "primary" stage during test runs has some advantages. 
    action: (Stage) -> Unit
    would actually provide the primary stage to setup the test stage.
    👍 1
  • h

    hastebrot

    11/02/2016, 6:26 PM
    setupPrimaryStage { stage -> MyApplication().start(stage) }
    would be a pretty simple use-case.
  • c

    carlw

    11/02/2016, 6:27 PM
    For the saga on deprecated javafx builders, read this email http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-March/006725.html
    👍 1
  • c

    carlw

    11/02/2016, 6:32 PM
    @hastebrot i don't think the parameter object is needed as much in Kotlin with named default parameters. You can just jump in and use setupPrimaryStage( action = ... unlike in Java where you'd have to use the position
  • h

    hastebrot

    11/02/2016, 6:35 PM
    there are probably more useful parameters to add. 
    preventDuplicateCalls = true
    for example, would explicitely state, that we prevent calling the toolkit startup multiple times (which causes JavaFX to throw a runtime exception).
  • e

    edvin

    11/02/2016, 6:36 PM
    Such a utility function will probably never be used with positional parameters, and that's really nice. You name whatever parameter you want to change, and that's that. Beautiful 🙂
1...555556557...2007Latest