On Wed Apr 3 20:21:51 2024 +0000, Jacek Caban wrote:
Why is it a separate vtbl from `builtin_info_t`? Do you expect a single object to use different vtbls for different properties?
The goal was to simplify the design for prop handlers in the rest of the code. The simplest for me was just like this for common cases: ```c if(!get_prop(..., &prop)) /* not found */
prop.vtbl->method(...) ``` In this design I wanted to have the vtbl tied to the specific prop. This is obviously needed for this: even an object with indexed props needs at least two operations on different props, the indexed ones and the dispex (named) props, which have different methods.
If I put it in `builtin_info_t`, then I'd either have to special case named props (they apply to all objects), or duplicate that in objects that have indexed props.
If I make it optional, I'd also have to check for the props methods being NULL and fall back to named props (unless I don't make it optional so that every object needs to have one). I mean, think of all the objects not having indexed props. Probably with helpers, else it becomes tedious. But honestly, if this is the case, the whole thing seems a little pointless. Wasn't the point of this to *avoid* checks like that everywhere?
Right now all props are filled with the vtbl in only few places, the rest of code doesn't care. Even for objects not having indexed props.