I'm not sure if you heard last week's podcast, but they have a way of working with breaking changes. Like in Java, Kotlin deprecates. Kotlin, like TornadoFX, can be more aggressive because of the current install base. Maybe some day that will change.

For now, Kotlin deprecates in the current release cycle. The podcast says that the team also provides migration tools within the IDE to coerce developers into making a correction beforehand. Then, unlike Java, Kotlin will remove the obsoleted syntax in the next release.

Things move fast in TornadoFX, but maybe it's worth pursuing that protocol: deprecate and provide migration in the current release and then remove in the release after that. Might be good practice.

@carlw Thank you, we'll do that. I'll introduce new overloads with map and deprecate the old. For workspace integration I'll only support the new syntax. A Workspace can find and inject a view, then dock it in one operation. This also supports parameters, so here I'll just support the map syntax right away.

While refactoring my CRM app I found some missing menu builders. The lack of a

<http://Menu.menu|Menu.menu>()

builder caused a sub menu to be added to the top level, since it would match the

<http://MenuBar.menu|MenuBar.menu>()

instead. Adding them now.

@edvin How about allowing for strongly typed

find<>()

so that you can pass actual arguments to a view constructor? I'm really not a fan of type-by-string.

Not sure if it is doable, but considering all this magic in Kotlin... 🙂

@permalmberg So you would append the parameters directly to the fragment or view you mean? So if

CustomerEditor

has a

customerId

field you could do

find<CustomerEditor> { customerId = 118 }

?

That would mean that the parameters in the class have to be mutable and that is not optimal..

But we could do:

find<CustomerEditor>(mapOf(CustomerEditor::customerId, 118)

perhaps. That could still work with

by param()

.

A little verbose, but type safe. And that's more important I think.

@edvin Type safety is much more important than saving a few key-presses. It removes the run-time bugs you get when you change `myName`to

myOtherName

but forget to update all

"myName" to <value>

everywhere that view is used.

Absolutely. This is going to be hard to do and keep backwards compatibility though. I wanted to go the route @carlw suggested, but we might have to break here..

@carlw's suggestion is a good one, but I'm sure that getting a type safe API is worth breaking backwards compatibility. Also, it is not something that will come as a surprise for the users of tfx since it is a major version.

I will make the change, then try to incorporate the backwards compatible, deprecated functions. Then we could just increment the minor version.

I'm trying out some trickery now.

It seems to work 🙂 Man, that felt good. Trying backwards compatible versions now.

Ok, but don't bend backwards just to make it work. I'm sure that people understand the need to break the API if presented with good arguments

I think I can make it 🙂

I will need some help with testing this.

Have you begun publishing the snapshot to maven?

No, not yet. I will set that up after I'm done with the Workspace and publish that 🙂

Doesn't jetpack work for you?

Didn't when I last tried...and I'm not using a Maven-project, remember? 🙂

Right 🙂 I commit a lot and I don't want to publish 75 snapshots a day to maven central, but I'll set up a self hosted repo that will get all the changes.

why not break it and call it 1.6.0?

@ron I thought we couldn't break unless it's a major?

@edvin why not? I don't see a problem with that, it is a snapshot after all

I think we should not do semver untill you feel stable enough

@ron Good point.