You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The "clunky" configuration class has the benefit of using a full parameter set and sealed polymorphism which are a way of compile-time verification, so that you cannot forget or misconfigure anything (assuming the data is correct) as opposed to runtime errors with a builder. Additionally, it is easier to inject the configuration instance when using dependency injection.
I however am not opposed to giving the user a choice and I see the aesthetic appeal of the DSL approach - but rather as an addition than a replacement.
Feel free to open a pull request with the desired interface and implementation. It could for example, be an additional overload of the invoke operator function on the KedisClient's companion object or a builder extension function as you described - both constructing the configuration class and calling the original operator I would suggest.
Currently, when creating a
KedisClient
, it is required that you use a clunkyKedisConfiguration
class, which leads to the following:kedis/example/src/commonMain/kotlin/CommonMain.kt
Lines 44 to 54 in 8d91700
If instead a DSL-style builder were offered, that would be amazing.
For example, the above code could be rewritten as something along the lines of
The text was updated successfully, but these errors were encountered: