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

[Dimitrie O. Paun]

On January 3, 2003 01:54 pm, Alexandre Julliard wrote:
> That's not another rule, it's just the standard behavior: functions
> are called the same way under Wine and under Winelib. If we use the
> wine_* functions in Wine too, then the rule is that in Winelib
> everything is identical, except that TRACE/ERR/WARN/FIXME have to be
> prefixed with WINE_. That's certainly easier and more consistent than
> having a separate rule for the debugstr functions that is different
> from everything else.

Granted. But there is a fundamental difference: all other wine_* functions
are so esoteric and rarely used, that we could even call them
wine_esoteric_function_... and no one would be bothered by it :) Besides,
they are meant to be called by some sort of portability layer in any
decent app anyhow, so you'll have a few instances of those in any app,
no matter how large. The debug functions are on the other hand the _most_ 
used functions in any app. A lot more than even the string functions. 
And those have names that are 6-8 char long. wine_dbgstr_point is 17 chars
long. And in a TRACE statement, you're not unlikely to use 2-3 of these:

  WINE_TRACE("(lprc=%s, lppt=%s, nSize=%d)\n", wine_dbgstr_rect(lprc),
             wine_dbgstr_point(lppt), nSize);

There is so many stuff in there... it's way too verbose, you don't know
what's going on there anymore. Contrast with this:

  TRACE("(lprc=%s, lppt=%s, nSize=%d)\n", dbgstr_rect(lprc), dbgstr_point(lppt), nSize);

or even:

  TRACE("(lprc=%s, lppt=%s, nSize=%d)\n", dbg_rect(lprc), dbg_point(lppt), nSize);

Obviously, if people are going to use our interface, they are not going
to use our long names directly. Why not allow them the option of using
our short names? How many apps are going to have a TRACE macro _if_ they
decide to use our debugging API? And if they do, they can -DWINE_NO_SHORT_DBG_API
and be done with it (or we can enable it only if -DWINE_SHORT_DBG_API).

-- 
Dimi.