Re: [PATCH v8 0/11] MR5444: jscript: Do not allocate dispex_prop_t for indexed props.

[Gabriel Ivăncescu]

On Wed Jun  5 18:25:43 2024 +0000, Jacek Caban wrote:
> > Well yes, of course they check for the object type compatibility, but
> > in the end they should still preserve their "function identity" instead
> > of being looked up from the object everytime, even if it's completely
> > detached from it.
> > I don't know what you mean by that, a pair like (dispid, iid) uniquely
> > defines a function identity. There is nothing special about dispid
> > except that we already need its lookup implemented, so that seems convenient.
> > See https://gitlab.winehq.org/jacek/wine/-/commits/func-call for a draft
> > of what I mean. It implements `call` only for legacy functions, but I
> > think it would scale to proper prototypes. It implements
> > bc02a4fe3be595448, but doesn't need unpleasant things like
> > `get_dispex_from_this` and uses the new interface instead (so committing
> > something like that would also be a good opportunity to upstream
> > "boring" parts of 81800d9dfa59f4fd8).
> > Extending it with accessors support should be straightforward. For
> > prototypes, we could just have entries for those functions both in the
> > instance and prototype objects. In instances, they would be not searched
> > when doing lookups by name, so the only way to use it would be through
> > `IJSDispatchHost`. For prototypes, they would be looked up, but an
> > attempt to call it would fail because prototypes don't actually
> > implement the required interface (so the result of the lookup would be
> > useful only for instances). It should also allow skipping 1ffeaa446613
> > with all its consequences. What do you think?
> > Well yes, a pair does work, but I wasn't passing the IID, only the
> > DISPID after making sure the object implements the required IID, since I
> > was delegating to the standard InvokeEx (well, almost), which only has
> > DISPID. But it was still ambiguous as I explained.

But since we pass the mshtml-internal tid (called iid in args) which is
opaque to jscript, I don't really see why this is better than passing
the `func_info_t` directly? Well IMO passing the pair is already more
complex and requires more lookups, more args, etc, but that's just me.

I haven't analyzed the rest yet, I'll look tomorrow as I have to go now,
but `get_dispex_from_this` is primarily useful for jscript proxies since
they can have arbitrary "this" passed. I was using it here (for legacy
function.call) mostly to introduce it earlier and have less to add on
the proxy patch which was already big enough as it is, but it's not its
main purpose. It was just a "split" attempt.

Are you sure you can get rid of it with your method?

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/5444#note_72511