Closed TehNeon closed 2 weeks ago
Interesting. @Flag
does not imply the parameter to be optional, but a Switch is always optional.
This may be easy to implement, but in a case where both a defaultValue
and a default value are provided, which should be prioritized?
@Command("test")
fun test(
@Switch(defaultValue = false) show: Boolean = true
) {
println("Show: $show") // ???
}
What I have in mind, is to restrict defaultValue
in Switch
to Java classes only, and require Kotlin classes to use default values instead.
That certainly makes sense with the @Flag
annotation. Whereas the @Switch
annotation is always considered Optional, it might be handy to have this functionality for. I haven't tested this, but theoretically throwing the @Optional
annotation on each of the parameters in my example should in theory make it function.
As for the defaultValue
portion of Switch, that becomes a weird problem due to not being able to tell if the user specified the value to default to false or not. I'd probably think though in the context of Kotlin it should probably default to the Kotlin default. But if it's possible to restrict the defaultValue
field to only Java classes, then that'd end up solving that issue.
Implemented in Lamp v4. @Switch
no longer defines a defaultValue. In Java, this will always be false. In Kotlin, the user has the option to specify a default value using Kotlin's syntax, which will default to false if they don't. Thanks for the notice.
Currently there is support for Kotlin default parameters for the Optional annotations, but this is lacking in other annotations such as Flag and Switch. If this logic were applied to the annotations, then in the example code here
example1
should work similarly toexample2
. Notably the example code is using the Kotlin default parameter functionality for the optional in both examples.