At 10:48 AM 4/11/2001 -0400, Andy Dougherty wrote:
>On Wed, 11 Apr 2001, Dan Sugalski wrote:
>
> > *) 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().
>
>But think also about embedding applications. If you want to embed perl
>into another program that has its own str_to_UTF() function, then
>
> #include "myprogram.h"
> #include <perl.h>
> /* ... */
> str_to_UTF();
>
>may get inadvertantly stuck with _Perl_str_to_UTF().
No. That's because you won't include perl.h when you embed perl in your
app--you'll include something like per/embed.h or perlembed.h that has just
the definitions for the bits perl exports for embedding. The embedding app
will have access to _Perl_str_to_UTF if it chooses to call it (adding in
the proper definitions, since they won't be there for it) but the #define
that added the _Perl_ prefix won't be around.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
