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

Dimitrie O. Paun dpaun at rogers.com
Fri Jan 3 17:15:49 CST 2003


On January 3, 2003 07:08 pm, Dan Kegel 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.

But we don't seem to reach a consensus on this one. So I will state
this for the record:
  -- I think using WINE_TRACE instead of TRACE inside of Wine makes
     little sense, and it will uglify everything. I strongly oppose it.
     Making the sources ugly is something we should not do lightly.
     People work on Wine for pleasure, and that definitely diminishes it.
     Making the most common thing more tedious falls into the same category.
  -- Let's think of the debugging API on it's own terms, not as part of
     wine. In fact, wine_ should not be part of the name at all. I suggested
     dbg_, even though Alexandre is right that it might cause problems.
     I'd like to remark that debugging APIs are special in that they are
     used orders of magnitude more often than any other API. In all natural
     languages, very common words often form exceptions to the rules of
     the language for shortness sake. Witness the verb "to be" in most
     languages. For this reasons, I don't think it's a mistake to treat it
     a bit differently. I suggest that we export symbols with the dbg_
     prefix by default, but we allow an easy way for the user to change
     that, maybe like so:
     #define WINE_DEBUG_API_PREFIX(s) d_##s
     #include <wine/debug.h>

Bottom line, I don't really care what we export. I do care what we use
internally. A great deal. In fact, if we export long symbols, I don't
think it matters how long they are, people will just invent short synonyms.
But why can't we invent short synonyms for Wine itself? :)

-- 
Dimi.




More information about the wine-devel mailing list