On Mon Oct 27 22:27:54 2025 +0000, Jacek Caban wrote:
I think it would be good to avoid using macros where possible, especially for generating entire functions. Instead, you could introduce typed array descriptors that hold the class, element size, and element getters/setters, e.g. `jsval_t get(const void*)` and `void set(void*, jsval_t)`. The constructor would take the descriptor, and the implementation could retrieve it from the "this" object when needed. Some sort of macro may still be useful, but something like: ``` #define ALL_TYPED_ARRAYS \ X(Int16Array) \ ... ``` should be enough. Sorry I don't understand, how will that help? The purpose of the macros generating the functions/`builtin_info_t` is to avoid boilerplate and copy-pasting (basically, almost-identical functions) for each Typed Array of a different type. The only things that change are e.g. variable types, the convert function, and so on. I can't use a function pointer since those functions take different types (and obviously compile to different code at machine level, like float vs int).
There's not much point to make indirection via getters/setters, since I'll have to write those methods for each Typed Array due to different types, and this was exactly what I wanted to avoid. Otherwise, without macros, I can simply just copy-paste the functions that are different (like the get/set) and change the type, what the macro is actually doing. Sort of how we have it for DataView. I mean, it will still be duplication, but at least no indirection. I just don't see the point of having another getter/setter indirection? Even if we go without macros. Also, do you mean we generate the `builtin_info_t` on the fly as well? Since that will also have to be duplicated (at the very least for the class!). Or can I use macro there at least? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9275#note_119904