RFR: 7903649: Field and global variables of array type should have indexed accessors

[Maurizio Cimadamore]

On Tue, 30 Jan 2024 17:05:47 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> It might also be useful to take some footprint measurements before/after.
>> Here are some rough measurements using libpython. There are approximatively 140 struct classes (out of ~240 generated files). Here's what I got:
>> 
>> Size of generated sources
>>     vanilla: 5.3M
>>     holder: 5.4M
>>     
>> Size of generated classes
>>     vanilla: 18M
>>     holder: 20M
>
> This looks like a good approach to me. I think we mostly care about the sources (esp. now that we always generate sources). The cost in terms of size doesn't seem bad. I'm assuming this is for an unfiltered extraction of libpython. I think our assumption is that most of the time, users that care about size will apply filters as well.
> 
> As far as source code itself goes. This doesn't look bad. TBH, I think it visually looks a bit cleaner since the constants are 'bagged up' nicely in a separate class that doesn't take up too much space. (at least at the moment. I think we need javadoc for the constant classes as well).
> 
> Considering discoverability, lets say someone wants to access the `x` field. When typing 'x', auto-complete would show 2 overloads of `x`, and then `x$constants`. That doesn't seem too cluttered, and I think it's clear from the name that the constant class is not for the common 'I just want to read `x`' use case, given the `$` in the name. (I think it's actually helping us out here).

I agree with all you said - e.g. overhead doesn't seem too prohibitive (but I'd like to experiment with windows.h as well, as that's a big stress test for this kind of stuff :-) ). And, as far as names are concerned, the IDE always prioritizes `x` over `x$constants`, so, in a way, the "good" symbols always show up first when auto-completing. I also agree that the code with the bag of constants looks cleaner compared to what we generate now.

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

PR Review Comment: https://git.openjdk.org/jextract/pull/198#discussion_r1471732054