Skip to content
This repository has been archived by the owner on Sep 28, 2024. It is now read-only.

[Refactorization & Cleanup] Controls.kt #824

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

SackCastellon
Copy link
Contributor

This PR was previously part of #815

Objectives

Changes

  • Applied the Kotlin Coding Conventions (https://kotlinlang.org/docs/reference/coding-conventions.html)
  • Sorted and grouped functions based on functionality.
  • Added some function variations with ObservableValue<X> instead of X. (Being X a given type)
  • Added some parameters and default values to be consistent.
  • Renamed some parameters to be consistent.
  • Changed signature of some functions to be more generic, ie: Property<String> changed to ObservableValue<String>. (Should not break existing code)
  • Removed some redundant functions.
  • Made some value parameters nullable to be consistent with the existing code.
  • Added support for more classes in EventTarget.properties.
  • Changed TextInputControl.stripNonNumeric to accept chars instead of strings.
  • Changed some properties keys, should not break existing code.

Applied the Kotlin Coding Conventions (https://kotlinlang.org/docs/reference/coding-conventions.html)
Sorted and grouped functions based on functionality.
Added some function variations with `ObservableValue<X>` instead of `X`. (Being X a given type)
Added some parameters and default values to be consistent.
Renamed some parameters to be consistent.
Changed signature of some functions to be more generic, ie: `Property<String>` changed to `ObservableValue<String>`. (Should not break existing code)
Removed some redundant functions.
Made some `value` parameters nullable to be consistent with the existing code.
Added support for more classes in `EventTarget.properties`.
Changed `TextInputControl.stripNonNumeric` to accept chars instead of strings.
Changed some properties keys, should not break existing code.
Copy link
Contributor

@tieskedh tieskedh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the shorter lines.
(at first i loved the long lines, as the lambda looked like a body.)
The new way makes it look very compact.

To make it even more compact, I would like to see a break after attach.

CreateSomething().attach{
....
}
Instead of a oneliner.

I don't like the : Unit.
(i personally also dot like the return-type of other functions, but as long as the functions don't have tests, I understand why you need them)

Ps. As you change things (other than the format), you should update the changelog

src/main/java/tornadofx/Controls.kt Outdated Show resolved Hide resolved
src/main/java/tornadofx/Controls.kt Outdated Show resolved Hide resolved
@edvin
Copy link
Owner

edvin commented Nov 3, 2018

This looks very good. Is it ready for merge?

Copy link
Contributor Author

@SackCastellon SackCastellon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are still a couple of things about which I would like to know your opinion @edvin.
I added some // FIXME comments to them, the reason why I didn't change them is that it could really break some existing code.

Another option could be to ignore them by now, leave the comments, and maybe fix them in the future.

// Button

fun EventTarget.button(
text: String = "", // FIXME This parameter is not nullable but in all the other existing functions it is nullable
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be nullable?

noinline op: Label.() -> Unit = {}
) = label().apply {
observable: ObservableValue<T>,
graphicProperty: ObservableValue<Node>? = null, // FIXME Inconsistent with all the other functions. There is no other function with ObservableValue<Node>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be graphic: Node like the rest of functions, or should all other functions have graphicProperty: ObservableValue<Node>??

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants