[PATCH 1/3] dmloader: COM cleanup of IDirectMusicLoader object.

Michael Stefaniuc mstefani at redhat.com
Thu Nov 8 06:41:52 CST 2012


On 11/08/2012 01:13 PM, Christian Costa wrote:
> 
> 
> 2012/11/8 Henri Verbeet <hverbeet at gmail.com <mailto:hverbeet at gmail.com>>
> 
>     On 8 November 2012 00:22, Michael Stefaniuc <mstefani at redhat.com
>     <mailto:mstefani at redhat.com>> wrote:
>     > But using just the capitalized letters from the name of the COM
>     class as
>     > a prefix and skipping the "Impl" would be in hindsight the better
>     > standard. There are still 170+ COM interfaces to clean up which is a
>     > sizable number regardless of it being just 13% of the total interface
>     > implementations, so we could still change the standard, especially as
>     > the existing function/method naming standard is not strictly
>     enforced; I
>     > didn't bother changing "offenders" if the name was reasonable.
>     > But I'm deferring this decision to Jacek / Alexandre as they are the
>     > drivers of the COM standardization in Wine. I don't mind too much as I
>     > can work with both patterns.
>     >
>     I think the only reasonable naming convention is to name things after
>     the implementation structure. In this case that would still end up
>     being "IDirectMusicLoaderImpl_...", but for a slightly different
>     reason. Where I agree with Nikolay is that "dmloader" would be a much
>     nicer name than "IDirectMusicLoaderImpl" for the implementation
>     structure as well, in which case you would also end up with
>     "dmloader_..." for method implementations.
> 
> 
> dmloader_IDirectMusicLoader_Method or dmloader_Method?
dmloader_IDirectMusicLoader_Method

> I was just saying removing the interface name was not a good thing imo
> or am I missing something?
Right, the interface name needs to be there as it matches the COBJMACROS
name. Basically the C macro with a prefix.

bye
	michael



More information about the wine-devel mailing list