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

[Dan Kegel]

Dimitrie O. Paun wrote:
>>Hmm.  I don't see a problem with WINE_TRACE myself.  It seems short enough,
>>and the source code gets read a lot more often than it gets written,
>>so the extra clarity is good.
> 
> Maybe I'm in my I_just_don't_get_it_mode, but I really don't! What clarity?
> Why is it important that the debug API is a Wine thing? Why not look at it
> as a 3rd party debugging API? Would you still call it WINE_TRACE? No, of
> course not, it would be silly. Why expose this implementation detail (that
> this is really implemented inside of Wine) in the interface? What possible
> benefit do you get out of it? Quite the contrary, it will just obfuscate
> the source. People think that very_long_identifiers_for_everything are
> a Good Thing. They are not. What about: WINE_SUPPORT_DEBUG_API_TRACE?
> Do we gain anything from knowing all that? I don't think so.

It doesn't have to be long, it just has to be unique, and have a prefix
that implies that it comes from Wine.  That way nobody is likely to
be confused about whose TRACE macro it is.  It's important when visually
scanning source code that it be fairly obvious what package each identifier
comes from, IMHO.

_W might be enough of a unique and common prefix...
- Dan


-- 
Dan Kegel
Linux User #78045
http://www.kegel.com