wine/ library/debug.c include/wine/library.h i ...

[Dimitrie O. Paun]

On January 3, 2003 06:48 pm, Dan Kegel wrote:
> Yes, but consider the poor sod who has already used the identifier TRACE
> (precisely because it's a convenient name, as you point out)
> and is trying to build with winelib.  Sure, we could have some switch
> to turn on and off the short names, but that gets hard to read...

I don't understand -- no winelib app include wine/debug.h, none will get
this problem. Unless they _explicitely_ decide to use our debugging API,
and they _explicitly_ #include <wine/debug.h>. In which case they are
aware of the problem. And in any event, they will want their own debug.h
header where they can do whatever renaming they want. In fact, if we
export just the long versions (which I'm OK with), they _will_ have to
have their own debug.h to provide more convenient names, in which case
they will probably be different from what we use in Wine anyway. Or
we can suggest our short names, so their debug.h can look like so:

#define WINE_NICE_DBG_API
#include <wine/debug.h>

Of course, MFC apps can do a number of trivail things to avoid the TRACE
conflict. So they are not a problem in any event.

It's simple, nice, easy to use and understand. In the long run we end up 
with a lot more uniformity.

But this is besides the point. What I'm arguing against is using the long 
names internally. This makes little sense, since I am virtually sure nobody
else will. So we will loose clarity, neatness, and convenience for the very
purpose of uniformity with some Winelib apps, that's not going to be there 
in the first place since they are not gonna use the long names, and are going
to invent their own anyhow.

What I'm saying is that if we provide people with an easy way to have 
convenient names, 99.99% will simply use those names, and we'll have a 
lot more of this uniformity. The few that choose not to, have a quite a
few easy ways to choose their own names.

-- 
Dimi.