On Fri Apr 12 12:33:28 2024 +0000, Jacek Caban wrote:
Generally, I think we should emphasize exposing properties as the intent of the interface, not "hooking" or "proxing". In this spirit:
IWineJSDispatch** GetProxyFieldRef();It will need a better solution, but I guess we may discuss it separately and keep this thread for properties.
HRESULT PropOverride([in] const WCHAR *name, [out, optional] VARIANT *value);This is essentially a property getter mixed with some "override" logic, right? Why not just use something like `PropGetInfo` paired with property getter call when appropriate?
HRESULT PropDefineOverride([out] struct proxy_prop_info *info);I don't know what it's for, hopefully it's redundant.
HRESULT PropInvoke([in] IDispatch *this_obj, [in] DISPID id, [in] LCID lcid, [in] DWORD flags, [in] DISPPARAMS *dp, [out, optional] VARIANT *ret, [out] EXCEPINFO *ei, [in] IServiceProvider *caller);Do we really need `this_obj` param? This really makes sense only on "call on the object" (aka. DISPID_VALUE). But I guess that we will want MSHTML functions to be represented by jscript function objects, right? In that case it shouldn't be needed to pass that to MSHTML. Calling a member like `InvokeEx` does is not really the way JavaScript calls work (at least not abstractly, as in spec). Member calls are really `func = propget(obj, name); call(func, this=obj, args...);`, this could be handled on jscript side with little MSHTML involvement. Calling a member in `IDispatch` style is really just an optimization to avoid allocating all functions objects that are not used as objects. With MSHTML using prototypes, it's less of the concern, so maybe we don't need to worry about that and just allocate them on demand? Or if we still want the optimization, we could provide a way for property getter to return something like (iid, dispid) pair that jscript would treat like a function or something along those lines. I'm also don't feel like `flags` argument is needed. I'd expect getters and setters to fit better in separate functions.
Ah, and `PropFixOverride` looks redundant too, it should be possible to avoid that by changing prototype handling on jscript side.