@carlw Thank you, Carl! Let's discuss here if needed!

@tieskedh I really like what you did with

SingleAssign

🙂

@edvin I was busy with the adapters and want to deliver two verssions to choose. The first is a basic refactoring and the second is a complete refactoring. What's the best way to do it? Two branches?

@tieskedh Looking at inc/dec now. They don't seem problematic to me, since they do update the original property. I thought they created new properties. What was the issue with these again?

@tieskedh Yes, branches

look at the documentation, inc/dec should not change the internals but return a new product. In that way kotlin can do post and pre-increment. By returning, a new instance,kotlin does only change the object in de new ref, but supports both post and preincrement. In other words, we can choose to change one or to change every reference. But if we change evey reference, like we do now, we don;t use the operator confirming the docs and postincrement fails

@tieskedh That's a very good point. I see why that would be problematic indeed.

Merged properties now.

@tieskedh I see you kept

subscriptions.computeIfAbsent(event, { HashSet() }).add(registration)

instead of changing to

getOrPut

in EventBus - why?

was busy with reification 😉 can be changed. There are a lot of small things that can be changed, but the best is if we add a small pause, where we refactor almost everything to the "good" kotlin, otherwise my refactoring bothers others who change the framework 😉 But this is one of the things that can be changed

One example would be when to use also and when apply and migrate to also and apply Then there are a lot of if/else, which can be refactored to when

@tieskedh No problem, it doesn't make any functional difference anyway, we can deal with it later.

Absolutely.

BorderPane.setRegion

needed to be made public to support reified generics/inline, but I guess that's fine.

where?

Layouts.kt, BorderPane.setRegion

It has to be done, or else you can't make the function inline, which you need to support reified generics.

I have no problems with this though. Just wanted to point it out.

I believe the acces modifiers don't have anything to do with inline/reified...

It does. You can't have an inline function call an internal function.

Think about it - an inline function is inserted at the call site, hence it would need access to all functions called within the inline code.

you're right.

I'm done with the review, have merged. My head is boiling. Hehe.. Great work!

Up to the adapters 😉

Cool, can't wait to see what you come up with!

I'd like to do a release of all this stuff at least two weeks before JavaOne, so we can iron out any issues it might cause.

I don't foresee much trouble though.

my first version is just using it in smartresize (I still need to place my functions for the outside in the main-directory) The next version, I want to use my adapters throughout the framework.

I'm very eager to test the performance impact of your SmartResize improvements!