At 11:04 AM 4/11/2001 +0100, Dave Mitchell wrote:
>I'm in the middle of drafting the PDD on coding conventions,
>and in the bit on naming things, I've run into the Perl 5 stuff
>that does
>
>#define foo Perl_foo
>
>etc.
>
>Its not clear to me whether this is for backwards compatibility or for
>convenience (or for something even more fiendish related to per thread
>objects etc).
Both, really. The problem with perl 5 (though it's arguably caused by a
Unix linker deficiency) is that there is no real API/internals line, and
all the functions from inside perl get exported to the world. This causes a
big problem when you link in extensions that link to other libraries, since
they tend to export routines with the same name and you get clashes when
linking. (Or worse, have to use both perl's foo() and your library's foo()
routine)
>My instinct is to say no, at the risk of making all the perl internals
>slightly more verbose.
My inclination is the opposite. In fact, what I'd propose is:
*) All exported perl functions and functionlike things have a Perl_ prefix
*) All exported data and dataish thigns have a PL_ prefix
*) All private routines have #defines to give them a _Perl_ prefix
*) All private data have #defines to give them a _PL_ prefix
*) Internal data and functions get referenced via the unqualified names
That way the internals can use the utility function str_to_UTF(), while the
world would see it (or, rather, not see it) as _Perl_str_to_UTF(). Less
typing for private things, and more for the much smaller (and probably not
used internally) set of public functions.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
