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

Support for nullable #20

Closed
MikolajKakol opened this issue Dec 23, 2019 · 9 comments
Closed

Support for nullable #20

MikolajKakol opened this issue Dec 23, 2019 · 9 comments
Labels

Comments

@MikolajKakol
Copy link
Contributor

Hi, it would be great to add nullable support. Any thoughts about this? If help is needed I could try.

@yshrsmz
Copy link
Owner

yshrsmz commented Dec 25, 2019

Could you elaborate on this?
What is the usecase of the null value as a constant?

@MikolajKakol
Copy link
Contributor Author

I'm using Gradle properties to read some constants. I'd like to model absence of them.

What I do is defining in local.properties proxy address for app and if it's not defined like on CI it's not installed on http client.

@yshrsmz
Copy link
Owner

yshrsmz commented Dec 27, 2019

Thanks for the detail!

Do you really need to distinguish null and empty string?
If not, I'd recommend you to use an empty string as an empty value, rather than using null.

@kuuuurt
Copy link

kuuuurt commented Dec 27, 2019

What about exposing a getHasKey method?

@MikolajKakol
Copy link
Contributor Author

With String it's kind of okay... however I also have some int's there and modeling it as -1/0 is just, you know :)

I feel that it would be a good addition to support nullable types since it's very deep in Kotlin roots.

@yshrsmz
Copy link
Owner

yshrsmz commented Dec 28, 2019

That sounds reasonable.
How would you like to configure nullable value? Any idea?

@MikolajKakol
Copy link
Contributor Author

I'm using kts. The current method is buildConfigField I was thinking about adding simple buildConfigNullableField.

However, it's a bit more wast problem. Right now we are constrained by Type enum in FieldSpec. I think it maybe could be a sealed class and we should allow a user to enter any primitive supported by the language.

I could help with two PR, one for simple nullable and one that would try to tackle that second matter. It could also provide some type safety before compilation.

    fun <T: Any?> buildConfigField(
        name: String,
        value: T
    ) 

would be a perfect method signature if possible.

@yshrsmz yshrsmz added the enhancement New feature or request label Dec 28, 2019
@yshrsmz
Copy link
Owner

yshrsmz commented Dec 28, 2019

buildConfigNullableField

looks nice 👍

Regarding the second suggestion, I'm not sure if it works well but let's see how it goes ;)

@yshrsmz
Copy link
Owner

yshrsmz commented Jan 25, 2020

I've just released 0.5.0 with changes from #21

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

No branches or pull requests

3 participants