[MDSAL-470] Add DataObject default methods Created: 03/Sep/19 Updated: 20/Jul/20 Resolved: 20/Jul/20 |
|
| Status: | Resolved |
| Project: | mdsal |
| Component/s: | Binding codegen, Binding runtime |
| Affects Version/s: | None |
| Fix Version/s: | 7.0.0 |
| Type: | Epic | Priority: | Medium |
| Reporter: | Robert Varga | Assignee: | Ilya Igushev |
| Resolution: | Done | Votes: | 0 |
| Labels: | pt | ||
| Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
| Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
| Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
| Sub-Tasks: |
|
| Description |
|
Generated DTOs capture their Object-related mechanics in two places:
Both of these should be indiscernible by the user, but there are subtle differences between them. It would be nice if we could eliminate those differences. A way to do that is to generate defaultToString() methods, like this: interface Foo extends DataObject { Bar getBar(); static String bindingToString(final Foo obj) { return "Foo [bar = " + obj.getBar() + "]"; } } Generated builders, as well as generated bridges can then do a simple: @Override public String toString() { return defaultToString(this); } which will result in the implementation being shared. This applies to hashCode()/equals() as well. |
| Comments |
| Comment by Robert Varga [ 03/Sep/19 ] |
|
These methods are not meant to for end-user consumption, so "default" may not be a great prefix to use. There is a potential improvement here, as with JEP 280 (Java 9) string concat can be expressed so that the JVM understands them and can produce near-perfect code. While we could leverage those capabilities at runtime (which is what matters), doing so is an untrivial amount of bytecode engineering. If we can emit that as compile-time code, javac will do all that work for us. That would mean ditching ToStringHelper/CodeHelpers from the picture, though – bytecode impact of that needs to be evaluated. |
| Comment by Robert Varga [ 03/Sep/19 ] |
|
I think we can allocate "binding", "java" prefix or similar. We could also overload hashCode() et al. with hashCode(DataObject), but that incurs wrath of static analysis, as well as bringing it closer to users (who would be confused by two equals() methods). Let's go with "binding", as in "bindingHashCode()", "bindingEquals()", "bindingToString()". |
| Comment by Robert Varga [ 03/Sep/19 ] |
|
Where augmentations are concerned, the methods should assume 'this' is an augmentation holder, and throw an IllegalStateExeption if that is not the case. This checking logic should be stored in CodeHelpers. |