On Tue Oct 28 17:36:49 2025 +0000, Gabriel Ivăncescu wrote:
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? As I said, some use of macros is fine, but I think some of the code that uses them doesn’t really need to. I’d need to try it myself to be sure, but I imagine we could have something like:
``` static double get_u8(const void *p) { return *(const UINT8 *)p; } static void set_u8(void *p, double v) { *(UINT8 *)p = double_to_int32(v); } static const ... Uint8Array_type = { .size = sizeof(UINT8), .get = get_u8, .set = set_u8 }; ``` Then, instead of passing the class id around, you could pass the type descriptor with `&name##_type`. We could do something similar for the remaining ones, like `prop_put` and `prop_get`. All conversions go through `to_number`, and that’s the annoying part since it may fail. We could just call it in the common code and let the per-type functions handle conversion to and from double. If you passed such a descriptor to `fill_typedarr_data_from_object` instead of the class id, you wouldn’t need the macro or the switch at all. While using the class id is possible, it seems inconvenient, so I’d be tempted to bend the abstraction slightly and store the array type descriptor pointer in `builtin_info_t` itself. `isView` could simply check whether it’s non-null, and “this” validation could use that instead of the id. I’m not entirely sure though, maybe that part (or more of above) is not worth it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9275#note_119932