Koin: Number-like strings in koin.properties

Created on 14 Nov 2018  路  8Comments  路  Source: InsertKoinIO/koin

(This is somewhere between a feature request and a bug report...)

Is your feature request related to a problem? Please describe.
There doesn't seem to be a way to get a string value from koin.properties when it looks like an Int or Float. For example, if koin.properties has:

OAUTH_APP_ID=1234567

then using

val appId: String by property("OAUTH_APP_ID")

throws an exception, because PropertyRegistry.import has added it as the detected Int and the cast in getValue<T> blows up.

Describe the solution you'd like
I'd like to have some mechanism to get a number-like string value from koin.properties (or, for that matter, system environment).

Describe alternatives you've considered
Surrounding the value with quotes, eg. OAUTH_APP_ID="1234567" keeps the quotes as part of the parsed value. However, I'm not sure that would resolve the issue when pulling values from the system environment.

Since any value should be able to be represented by a string, perhaps PropertyRegistry.getValue<T> could be altered to return the type guessed during import OR a String when that's what is requested?

Target Koin project
koin-core

Edit
This cannot be worked around when the value being parsed overflows. OAUTH_APP_ID=386226214594673 will end up giving the value 386226209161216, and no amount of casting will fix that.

We also see this limited to Int and Float but not for other basic types like Boolean. Perhaps all values should be imported as strings and the casts are only performed with plucking the values out?

core accepted open-contribution

All 8 comments

As a workaround, you can pull the value out as Any:

val appId: String by lazy { getProperty<Any>("OAUTH_APP_ID").toString() }

However, this requires you know in advance that your property may be converted to a numeric type, which may not always be the case.

Thanks for triaging this, @arnaudgiuliani . The workaround already doesn't apply to one of my cases unfortunately, as I'm running into the overflow issue experienced in my last edit. If there's anything you're aware of in the meantime, or have a solution you'd be interested in seeing a PR for, please let me know.

If you have any proposal @doxavore , let us know.

would require someone to propose something around that 馃憤

I think PropertyRegistry should keep all values as String since that's what Properties does.
Then users can convert the string value to anything they want.

Then I tried to do the smart cast in Koin like this:

    inline fun <reified T> getProperty(key: String): T? {
        val stringValue = _propertyRegistry.getProperty(key) ?: return null
        return when (T::class) {
            Int::class -> stringValue.toIntOrNull() as T?
            Float::class -> stringValue.toFloatOrNull() as T?
            Double::class -> stringValue.toDoubleOrNull() as T?
            else -> stringValue as T
        }
    }

But in order to check the type in runtime, I have to convert the function to inline function to use reified type.
Everything works perfectly except the function cannot be called by Java code since inline function is Kotlin-only feature.

Support Java might still be very important so this proposal is not good. But I still think PropertyRegistry should only have String values. So another proposal is:

  • Change all getProperty functions to only accept String values. (Breaking change)
  • Create some extension functions for Koin for convenience like getIntProperty(key: String)

How do you think? I can create a PR for it if you think it's okay.

I personally like the idea of getProperty always returning a string value and using extension functions for typed values. This would be the least surprising thing and the least likely to have subtle bugs.

Can you propose a PR @Swordsman-Inaction ?

Thanks, continuing with PR 馃憤

Was this page helpful?
0 / 5 - 0 ratings

Related issues

TedHoryczun picture TedHoryczun  路  4Comments

guymclean picture guymclean  路  3Comments

CristianMG picture CristianMG  路  3Comments

luna-vulpo picture luna-vulpo  路  4Comments

LukasAnda picture LukasAnda  路  3Comments