[PATCH v2 2/4] windows.media.speech: Implement IInstalledVoicesStatic stub.

Zebediah Figura (she/her) zfigura at codeweavers.com
Fri Mar 5 15:06:43 CST 2021



On 3/5/21 1:02 PM, Jacek Caban wrote:
> On 05.03.2021 17:21, Zebediah Figura (she/her) wrote:
>>> Static object also don't really need a structs like
>>> windows_media_speech, but it's fine to have it. However,
>>> IVectorView_VoiceInformation doesn't really belong to
>>> windows_media_speech object as it looks like a separate object.
>>
>> As far as I can tell, it's not a mutable interface and therefore
>> doesn't need to be made into a separate object, right?
> 
> 
> I assume that by separated object you mean separated C structs to
> represent multiple COM objects. If we have separated QueryInterface
> implementations, then we deal with separated COM objects even if they
> are represented by a single C struct (and share ref count, which is not
> great).
> 
> 
> And yes, technically it doesn't need to be a separated struct, but when
> I look at something like that:
> 
> struct windows_media_speech
> 
> {
>       IActivationFactory IActivationFactory_iface;
>       IInstalledVoicesStatic IInstalledVoicesStatic_iface;
>       IVectorView_VoiceInformation IVectorView_VoiceInformation_iface;
>       LONG ref;
> };
> 
> 
> the first (and usually right) impression is that it's an object that implements 3 interfaces (as in, any of its QueryInterfaces will support all those interfaces). And yet in this case it's not true. I'd really need to read all QueryInterface implementations to learn that it's really a struct representing two separated COM object. It could be clarified with a comment, but I don't really see why in this particular case
> we'd want a single struct at all. It doesn't seem to be making anything easier. There are cases when something like that may be useful, but this one doesn't seem one of them.

Well, it's one less allocation, which is always nice.

Definitely the interface should be visually separated in the 
windows_media_speech structure, though.

> 
> 
> BTW, as long as those object implement ref counting, they are not exactly immutable.

True, but I at least hope we're past the point where programs abuse COM 
refcounting all the time, and that nonsense can be confined to things 
like ddraw and dmusic ;-)

> 
> Jacek
> 




More information about the wine-devel mailing list