-
-
Notifications
You must be signed in to change notification settings - Fork 212
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
replace property
and returnValueOf with feature
or similar
#40
Comments
property
and returnValueOf with map
property
and returnValueOf with map
or similar
I am no longer sure if |
property
and returnValueOf with map
or similarproperty
and returnValueOf with feature
or similar
To workaround the kotlin bug concerning multiple overloads with function type we could introduce
where FeatureProvider in turn provides helper functions to construct features out of properties and functions. The only problem here, Kotlin has also bugs concerning function reference of overloaded functions and expecting KProperty/KFunction :(
or we could start of with |
Platform (JVM and/or JS): JVM/JS
Code related feature
setup
feature as such
We could furthermore consider to add
featureRef
as alternative where one can use a bounded reference:Yet, considering the problems we still encounter due to Kotlins problems with overloads involving KFunction types, I am not sure if it is really a good idea to allow bounded reference.
Alternatively we could also go with a
Pair<String, T>
:But that involves quite a bit of boilerplate. On the other hand it would allow mapping over multiple levels:
We could reduce the boilerplate for JS by using eval but eval is evil and we would loose type safety so probably not a good idea.
The good thing about map` would be that we hide the implementation detail whether firstName is actually a property or a getter. I stumble over this problematic from time to time when I deal with Java Code where Kotlin provides property syntax even for getters. But that's not the case for function references. So the following is the result which is... not so nice:
We cannot get rid of the confusion that
Person
does not have aname
property, but we can at least lower the confusion by providing one single method.Care has to be taken due to current bugs concerning overloading in Kotlin.
The text was updated successfully, but these errors were encountered: