On Wed, 15 Mar 2023 19:33:19 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java
>> line 208:
>>
>>> 206: static boolean isUnbox(Binding binding) {
>>> 207: return switch (binding) {
>>> 208: case Binding.VMStore unused -> true;
>>
>> I wonder... here it might be better to capture the box/unbox nature of a
>> binding in a virtual method in the binding class? E.g. isBox(), isUnbox() ?
>
> I prefer this approach, to be honest, since the logic for all the different
> binding operators is in one place. It gives an overview of which operators
> are expected in an unboxing recipe. Making them virtual methods would put
> quite a bit of visual distance between the different `true`/`false` values.
>
> I've been through the Binding file quite a bit, and the amount of
> scrolling/searching needed to find a particular implementation is kind of
> annoying.
To pull on that string some more. I think we should move the implementations of
various Binding::verify methods here, or perhaps into a separate
BindingVerifier class.
Ditto for the Binding::interpret implementations. They could be moved to
BindingInterpreter. The Binding class would just be left as a simple bag of
records + documentation for each operator.
The main motivation for this would be that, if you're looking at e.g.
interpretation in `Binding`, there's a lot of noise that you have to filter
through. I think it makes more sense to group these things into classes (for
specialization/verification/interpretation), where all the code in a class is
logically related.
-------------
PR: https://git.openjdk.org/jdk/pull/13047
