Okay, I think we're talking at cross-purposes at the moment.
There are exactly 6 things that need prefixes added:
1) Functions that are explicitly exported as part of the API
2) Functions that are internal only, but we can't stop being exported
because lots of linkers suck
3) Global data that we export. (If any)
4) Global data we can't not export. (For the same reason as #2)
5) Macros we explicitly put in the headers that extensions or embedders
include.
6) Typedefs and structure definitios that we explicitly export
Generally speaking, I don't *want* the core to use any functions in class 1.
Classes 2 and 4 need our "internal" prefix, and only because so many
linkers are dead-stupid and won't let us restrict what functions and data
we export. Having convenience prefixing macros is fine with me for
these--we're adding them because we're forced to, and I don't see any
reason to be inconvenienced because of stupid linkers.
Class 3 will probably be really, *really* small, and requiring a prefix in
the code's OK with me.
Classes 5 and 6 will likely be very small, and once again I don't see a
problem with convenience macros in the core source to add prefixes.
Now, for all of these things *not* part of one of the core chunks
(including extensions and possibly other major pieces of the core) you'd
have to type in the prefixes. That's fine.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
