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
T getSomeValue() that returns a private value T someValue with the same type and doesn't get any arguments can be converted to a Dart's getter T get someValue – potentially only under a config flag
void setSomeValue(T t) that gets a value of type T and returns void can be converted into a Dart's setter set someValue(T t) – potentially only under a config flag - [ ] get methods that only get a single argument can be converted to operator [] – potentially only under a config flag - [ ] put methods that only get two arguments can also be converted to operator []=. We still probably want to generate put because put usually returns the value in Java while []= returns void – potentially only under a config flag
equals method can overload operator == and hashCode can override the hash code getter.
More conversions that can make the code more idiomatic to Dart? Feel free to suggest.
Overall this is similar to what most java serialization libraries do with getters / setters. (JSON, ORMs & DB drivers). They try to convert getters and setters into fields / columns.
I actually have a locally drafted proposal about better supporting such PoD (plain old data) types, but I think we are too early in the roadmap to discuss that feature.
Now that we've split the collections into an inner layer that's just the raw JNIgen output, and a hand written adapter layer that looks more Darty, there's less incentive to convert [] and []=, since the adapter layer is the one that has these operators. So I'll just do the getter/setter transform for now.
Activity
mahesh-hegde commentedon Jun 21, 2023
isField.Overall this is similar to what most java serialization libraries do with getters / setters. (JSON, ORMs & DB drivers). They try to convert getters and setters into fields / columns.
I actually have a locally drafted proposal about better supporting such PoD (plain old data) types, but I think we are too early in the roadmap to discuss that feature.
[-]☔ Idiomatic conversions[/-][+]☂️ Idiomatic conversions[/+]mit-mit commentedon Jan 25, 2024
Big +1 for doing the first two!
That would be similar to what Kotlin to Java interop does: https://kotlinlang.org/docs/java-interop.html#getters-and-setters
HosseinYousefi commentedon Jan 25, 2024
Kotlin is doing some other conversions for operators as well but the documentation is somewhat vague about it: https://kotlinlang.org/docs/java-interop.html#operators
For example
list[i]turns intolist.get(i), and so on... (Similar to the other proposed conversions in this issue).liamappelbe commentedon Mar 12, 2026
Now that we've split the collections into an inner layer that's just the raw JNIgen output, and a hand written adapter layer that looks more Darty, there's less incentive to convert
[]and[]=, since the adapter layer is the one that has these operators. So I'll just do the getter/setter transform for now.