[MDSAL-453] Eliminate the diffence between null and empty nodes Created: 21/May/19 Updated: 21/Apr/20 Resolved: 21/Apr/20 |
|
| Status: | Resolved |
| Project: | mdsal |
| Component/s: | Binding codegen, Binding runtime |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Medium |
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Epic Link: | Binding empty lists/maps |
| Description |
|
Binding list/map treatment should make sure we do not return nulls here, as it imposes additional burden on the user. When a list/map does not exist, we should return an empty immutable list/map, so that things are kept consistent. This automatically means DTOs do not leak mutable maps, no matter what. Even when a map is initialized (empty in this case, but we are generalizing here) to an HashMap in the builder, it is fair for the resulting object to return an immutable implementation (i.e. an empty ImmutableMap). |
| Comments |
| Comment by Robert Varga [ 17/Dec/19 ] |
|
As part of the epic, we are really going the other way – we are turning empty maps into nulls, as we provide utility methods to treat them as non-null. This will lower the non-leakage guarantees, but will make it easier for users to transition. |
| Comment by Robert Varga [ 21/Apr/20 ] |
|
As noted previously, we are really doing the opposite, allowing the user to use nonnullFoo() or getFoo() to make a choice between empty or nullable collections. |