P3
Consider the following declaration:
```
struct Point2d {
double x;
double y;
};
```
This generates the following code (details are omitted):
```
public class Point2d {
public static MemoryLayout $LAYOUT() {
return constants$0.const$0;
}
...
}
```
It is not clear, when looking at this code, what is the layout of a point struct. To discover that, we have to chase one of the constant classes generated by jextract:
```
final class constants$0 {
static final StructLayout const$0 = MemoryLayout.structLayout(
JAVA_DOUBLE.withName("x"),
JAVA_DOUBLE.withName("y")
).withName("Point2d");
```
This is also true when looking at function wrappers inside header classes.
While the constant class-based translation is an attempt to optimize the performance of the generated bindings, there is a valid argument to be made that the code generated by jextract is now unreadable, and not self-contained. This makes it hard, for instance, to take jextract output and copy-and-paste it somewhere else.
Given that jextract now supports filtering options as well, it is perhaps worth asking how much should laziness affect the shape of the generated bindings. That is, if developers only want to call 2-3 functions they can simply tell jextract to only emit bindings for these 2-3 functions, and avoid initialization of unrelated stuff.
If laziness of the header class is still perceived as important - e.g. because a library like windows.h might contain hundreds (if not thousands) of method handles, we could consider an approach where a local holder class is used for each method handle wrapper. As for structs and callbacks, moving the constants elsewhere hardly buys much.
```
struct Point2d {
double x;
double y;
};
```
This generates the following code (details are omitted):
```
public class Point2d {
public static MemoryLayout $LAYOUT() {
return constants$0.const$0;
}
...
}
```
It is not clear, when looking at this code, what is the layout of a point struct. To discover that, we have to chase one of the constant classes generated by jextract:
```
final class constants$0 {
static final StructLayout const$0 = MemoryLayout.structLayout(
JAVA_DOUBLE.withName("x"),
JAVA_DOUBLE.withName("y")
).withName("Point2d");
```
This is also true when looking at function wrappers inside header classes.
While the constant class-based translation is an attempt to optimize the performance of the generated bindings, there is a valid argument to be made that the code generated by jextract is now unreadable, and not self-contained. This makes it hard, for instance, to take jextract output and copy-and-paste it somewhere else.
Given that jextract now supports filtering options as well, it is perhaps worth asking how much should laziness affect the shape of the generated bindings. That is, if developers only want to call 2-3 functions they can simply tell jextract to only emit bindings for these 2-3 functions, and avoid initialization of unrelated stuff.
If laziness of the header class is still perceived as important - e.g. because a library like windows.h might contain hundreds (if not thousands) of method handles, we could consider an approach where a local holder class is used for each method handle wrapper. As for structs and callbacks, moving the constants elsewhere hardly buys much.
