2012/11/8 Michael Stefaniuc <mstefani@redhat.com>
On 11/08/2012 01:13 PM, Christian Costa wrote:
>
>
> 2012/11/8 Henri Verbeet <hverbeet@gmail.com <mailto:hverbeet@gmail.com>>
>
> � � On 8 November 2012 00:22, Michael Stefaniuc <mstefani@redhat.com
> � � <mailto:mstefani@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

Henri said the other. It seems there is no consensus. ;)�

> 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.

It is what I was thinking. Match the macros and just add a class prefix if needed
or just _ to avoid the conflict.
Christian