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
Is your feature request related to a problem? Please describe
As described in #205, there are some type-safety problems with Option. A simple fix would be to return Object when retrieving the value of an Option, but that would leave the problem of knowing how to turn a String parsed out of a URL into the type that the Option requires.
Describe the solution you'd like
Having discussed this with @mp911de, if an Option held a Class<T> for the type of its value, ConnectionUrlParser could then be configured with a BiFunction<Option<?>, String, ?> that can convert a String into the required type for a given option.
Describe alternatives you've considered
An alternative would be to keep conversion local to a specific option with a method that's something like this:
The option itself would then be armed with a converter function that can turn a String from URL parsing into the required type. This provides more flexibility as each option can decide on how any conversion is performed. However, this creates the possibility for inconsistent conversion across different options. It also exposes something that's really a URL parsing concern in the API of Option. Plugging a conversion strategy into connection URL parsing would place the solution next to the source of the problem.
The text was updated successfully, but these errors were encountered:
Feature Request
Is your feature request related to a problem? Please describe
As described in #205, there are some type-safety problems with
Option
. A simple fix would be to returnObject
when retrieving the value of anOption
, but that would leave the problem of knowing how to turn aString
parsed out of a URL into the type that theOption
requires.Describe the solution you'd like
Having discussed this with @mp911de, if an
Option
held aClass<T>
for the type of its value,ConnectionUrlParser
could then be configured with aBiFunction<Option<?>, String, ?>
that can convert aString
into the required type for a given option.Describe alternatives you've considered
An alternative would be to keep conversion local to a specific option with a method that's something like this:
The option itself would then be armed with a converter function that can turn a
String
from URL parsing into the required type. This provides more flexibility as each option can decide on how any conversion is performed. However, this creates the possibility for inconsistent conversion across different options. It also exposes something that's really a URL parsing concern in the API ofOption
. Plugging a conversion strategy into connection URL parsing would place the solution next to the source of the problem.The text was updated successfully, but these errors were encountered: