At 10:46 AM 4/11/2001 -0400, Bryan C. Warnock wrote:
>Okay, I may be slow, but I make mistakes. Why 3 & 4 below?
>Having the bare names doesn't solve any of the linking/clobbering issues,
>and why have #defines giving public names to routines you're not exporting?
It does fix the link issues, though. perl6.so won't ever have an
unqualified function in it--they'll all have either a Perl_ or _Perl_
prefix on them, and all global data will have a PL_ prefix on it.
Whether you can use the routines unqualified or not depends on whether
you're in core code (with the core headers) or in extension or embedding
code (presumably using the perlextend.h or perlembed.h headers)
>This isn't to bypass the 'leading underscore' reservation, is it?
Nah, not really.
>On Wednesday 11 April 2001 10:29, Dan Sugalski wrote:
> > 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
