Revxrsal / Lamp

A modern annotations-driven commands framework for Java and Kotlin
MIT License
202 stars 38 forks source link

[Feature] Kotlin default parameters for other annotations #93

Closed TehNeon closed 2 weeks ago

TehNeon commented 6 months ago

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 to example2. Notably the example code is using the Kotlin default parameter functionality for the optional in both examples.

    @Command("example1")
    fun example1(
        sender: Player,
        @Optional optional: String = "optional",
        @Flag("rows") flag: Int = 6,
        @Switch switch: Boolean = true
    ) {
        sender.sendMessage("example1 - $optional - $flag - $switch")
    }

    @Command("example2")
    fun example2(
        sender: Player,
        @Optional optional: String = "optional",
        @Flag("rows") @Default("6") flag: Int,
        @Switch(defaultValue = true) switch: Boolean
    ) {
        sender.sendMessage("example2 - $optional - $flag - $switch")
    }
Revxrsal commented 6 months 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.

TehNeon commented 6 months ago

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.

Revxrsal commented 2 weeks ago

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.