-
Enhancement
-
Resolution: Fixed
-
P3
-
None
-
repo-panama
The code for ABI classification went a bit back and forth: we started off with the idea of making classification attributes transparent - but we didn't like how much that affected the javadoc of the CLinker interface.
We then tried to hide classification attributes, by creating a custom CValueLayout subclass; this had its problems: instances of this class were not equals() to plain ValueLayout, but users could not see why. There was an inevitable tension to make CValueLayout public, which we did.
However, even making CValueLayout public is not enough - after all clients like jextract need access to the classification information - so we ended up adding a public Kind enum in CValueLayout which is publicly accessible.
We now come to full circle: classification properties are still exposed (as they were at the start), but we have gone down the path of making layout subclassable, which raises more questions than it solves: dealing with immutable data structures like these is problematic - and layouts are very tedious to subclass, especially when it comes to covariant overrides.
For all these reasons, we should just embrace the current Kind enum as the "one and true" classification scheme, and expose it in CLinker - attach it to layouts using the layout attribute mechanism, and just forget about CValueLayout.
We then tried to hide classification attributes, by creating a custom CValueLayout subclass; this had its problems: instances of this class were not equals() to plain ValueLayout, but users could not see why. There was an inevitable tension to make CValueLayout public, which we did.
However, even making CValueLayout public is not enough - after all clients like jextract need access to the classification information - so we ended up adding a public Kind enum in CValueLayout which is publicly accessible.
We now come to full circle: classification properties are still exposed (as they were at the start), but we have gone down the path of making layout subclassable, which raises more questions than it solves: dealing with immutable data structures like these is problematic - and layouts are very tedious to subclass, especially when it comes to covariant overrides.
For all these reasons, we should just embrace the current Kind enum as the "one and true" classification scheme, and expose it in CLinker - attach it to layouts using the layout attribute mechanism, and just forget about CValueLayout.