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.