Coming back to the original question of whether its okay to have
convenience macros foo() to save typing perl_foo(),
I'm going to have one more go at arguing against it....
We're all agreed that externally linked entities (functions and global
vars) need a perl_ prefix to avoid name clashes when linking with non-perl
stuff. Even stuff that is hidden behind an API needs a prefix if the
API is implemented over several source files. We havent actually addressed
yet all the other stuff that can have name clashes, like structs, macros etc.
If we have the convenience macro
#define foo perl_foo
Then we have to consider whether it is in scope for each of the
following permutations
i) its internal to an API
ii) its exported by an API
X
a) its a function
b) its a variable
c) its a macro/struct/typedef/enum
X
1) its defined within the files internal to a particular subsystem
2) its defined within the rest of the perl core
3) its defined in extensions
4) its defined where perl is embedded in something else
Anyone want to enumeriate for each of the 24 permutations whether we
can hide the perl_ (or PERL_ or whatever) prefix?
My strong inclination is to never hide it. It involves extra typing
(ie :map! #1 perl_) and makes the src code slightly more voluminous.
Set against that, it removes one layer of macro complication from a
system bedevilled by macroitis, and removes the necessity of deciding
(or remembering) which of those permutations above apply. It also removes
any residual risk of name clashes within those bits where the shortcut *is*
defined.
Note that internally within perlio.c etc, most stuff seems prefixed with
PerlIO without apparent difficulty....
Yours in easer anticipation!
Dave M.
