-
Notifications
You must be signed in to change notification settings - Fork 364
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
A proposal for supporting references to synthetic Java properties #329
A proposal for supporting references to synthetic Java properties #329
Conversation
This feature has lots of problems. It needs extensive testing. Consider public class Jaba {
public String publicField;
public String getPublicField() {
return publicField;
}
public static String getStaticFoo() {
return "";
}
private String privateField;
public String getPrivateField() {
return "";
}
public String getALLAREUPPERCASE() {
return "";
}
public String getGetFoo() {
return "";
}
public String getFoo() {
return "";
}
public String getClassClash() {
return "";
}
class getClassClash {
}
public static boolean isStaticFoo() {
return true;
}
} import kotlin.reflect.KProperty
fun main() {
val a = Jaba::publicField // resolved to the field (but should be ambiguity)
val b = Jaba::privateField // resolved to the method (expected)
val g = Jaba::getClassClash // Overload resolution ambiguity (expected)
Jaba().allareuppercase // does this weird Kotlin feature interfere with synthetic properties?
// Probably unrelated because it's only about functions
val c = Jaba::staticFoo // Unresolved reference
val d = Jaba::isStaticFoo // works as KFunction
val e = Jaba::getFoo // is getGetFoo() or getFoo() ?
val f: KProperty<String> = Jaba::getFoo // is getGetFoo() or getFoo() ?
// ^ e and f are different
} I expect the KEEP document to prove that we cover all the cases Corner cases are co-authored-by: Simon Ogorodnik, Pavel Mikhailovskii, Nikita Bobko UPD: covered by |
Co-authored-by: Alexander Udalov <udalov@users.noreply.github.com>
Co-authored-by: Alexander Udalov <udalov@users.noreply.github.com>
…s approved KEEP document: Kotlin/KEEP#329
…s approved KEEP document: Kotlin/KEEP#329
As was mentioned above, all features requiring `kotlin-reflect`, such as `KProperty::visibility` worked incorrectly. | ||
Instead of somehow taking into account the synthetic nature of the property, they tried to access a Java **field** of the same name. | ||
If no such field existed a run-time exception would be thrown. | ||
In particular, that meant that calling `propertyReference.seter(value)` would bypass the original setter method and write |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In particular, that meant that calling `propertyReference.seter(value)` would bypass the original setter method and write | |
In particular, that meant that calling `propertyReference.setter(value)` would bypass the original setter method and write |
Co-authored-by: Alexander Udalov <udalov@users.noreply.github.com>
No description provided.