Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversion from base types #37

Open
serras opened this issue Apr 6, 2022 · 3 comments
Open

Conversion from base types #37

serras opened this issue Apr 6, 2022 · 3 comments

Comments

@serras
Copy link
Member

serras commented Apr 6, 2022

(From a conversation on Slack)

The idea is to automatically provide conversions or constructors from basic types to classes with invariants.Some ideas:

  • For value class we create from the base type to the type with invariants, as in the case above. Maybe we should return String? instead.
@JvmInline
value class String5(val value: String) {
    init {
        require(value.length < 5)
    }
}

fun String.asString5() = if (this.length < 5) {
    String5(this).right()
} else {
    "String '$this' should be smaller than 5".left()
}
  • Conversely, we could add pseudo-constructors in the companion object which return the type but nullable.
@JvmInline
value class String5(val value: String) {
    init {
        require(value.length < 5)
    }

    companion object {
        fun attempt(value: String): String5? = ...
    }
}
@serras
Copy link
Member Author

serras commented Apr 6, 2022

My current preference is to do (1), since we can do it without requiring an empty companion object (as happens with the lenses plug-in). However, I see the benefit of providing a generic way to say "I don't know whether all the invariants are satisfied here, so please return a nullable".

Any other ideas, @raulraja @nomisRev?

@raulraja
Copy link
Member

raulraja commented Apr 6, 2022

This method in the previous refined types plugin used to be based on nullable too. I think nullable is better so we don't impose a dependency on arrow core or have to provide a custom validation class, also don't allocate just to validate. Alternatively, we could have the plugin automatically codegen versions for Either or ValidatedNel if we find arrow.core is in the user classpath.

I also prefer the first option so we don't have to provide a companion.

@nomisRev
Copy link
Member

nomisRev commented Apr 7, 2022

I also prefer the first option so we don't have to provide a companion.

I've never wanted this for Arrow Optics, but there is still no way to currently do this unless you're a compiler plugin. KSP cannot add a companion either but Arrow Analysis should be able to do this since it can add it, right? KotlinX Serialization also adds a companion object on the fly if it's not present.

I think nullable is better so we don't impose a dependency on arrow core

100% agreed.

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

No branches or pull requests

3 participants