[foreign-abi] [Rev 01] RFR: Rename SystemABI to ForeignLinker, and move C support to a separate class.

[Maurizio Cimadamore]

On Mon, 18 May 2020 12:20:59 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> if we have already C somewhere in the class name, there's a question as to whether constants should drop their C-ness
>>> (e.g. `C.C_BOOL` looks odd).
>>> Thought about this; C.C_BOOL and C.Win64.C_BOOL become C.BOOL,
>>> C.Win64.BOOL. That seems fine. Then there's also static import variants;
>>> C_BOOL, Win64.C_BOOL that go to BOOL and Win64.BOOL. I feel like for the
>>> C_BOOL -> BOOL case some information is lost, and that's the most common
>>> case we have it seems. But, maybe it's clear enough from the context
>>> that a C layout is being used? I think the main risk is confusing with
>>> Java carrier types or layouts (since the names are similar. Feeling a
>>> little on the fence about it, so I held off on the first revision.
>> 
>> I was about to mention when I wrote my message that, one counter argument to my proposal was that, if the code used a
>> static import at the top (and you have few examples in your patch) then the code would just use `BOOL`, which might
>> also be a bit thin.  In the end, perhaps this is tied with the support class called just `C`; e.g. `C.C_Bool` looks a
>> tad weird, `C<something>.C_BOOL` (e.g. `CSupport.C_BOOL`) perhaps not as much.
>
>> In the end, perhaps this is tied with the support class called just `C`; e.g. `C.C_Bool` looks a tad weird,
>> `C<something>.C_BOOL` (e.g. `CSupport.C_BOOL`) perhaps not as much.
> 
> I agree, it doesn't look as weird after applying the rename to CSupport locally.

Renaming looks good - is there a reason as to why the Cstring was left in place as a test util? If you prefer to
address as a followup that's ok with me.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/174