Re: Perl_foo() vs foo() etc

2001-04-13 Thread Dan Sugalski
At 10:24 PM 4/13/2001 +0100, Nicholas Clark wrote: >On Fri, Apr 13, 2001 at 04:05:05PM -0400, Dan Sugalski wrote: > > 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

Re: Perl_foo() vs foo() etc

2001-04-13 Thread Uri Guttman
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes: NC> Presumably there are internal functions that aren't part of the NC> public API, but because they are used in more than 1 source file NC> do need external linkage. Or were your "linkers are dead-stupid" NC> words meaning that we

Re: Perl_foo() vs foo() etc

2001-04-13 Thread Nicholas Clark
On Fri, Apr 13, 2001 at 04:05:05PM -0400, Dan Sugalski wrote: > 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

Re: Perl_foo() vs foo() etc

2001-04-13 Thread Dan Sugalski
At 01:21 PM 4/13/2001 +0200, Kai Henningsen wrote: >[EMAIL PROTECTED] (Dan Sugalski) wrote on 12.04.01 in ><[EMAIL PROTECTED]>: > > > At 12:16 AM 4/13/2001 +0200, Kai Henningsen wrote: > > >[EMAIL PROTECTED] (Dan Sugalski) wrote on 11.04.01 in > > ><[EMAIL PROTECTED]>: > > > > > > > *) All priv

Re: Perl_foo() vs foo() etc

2001-04-13 Thread Dan Sugalski
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 w

Re: Perl_foo() vs foo() etc

2001-04-13 Thread Dave Mitchell
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

Re: Perl_foo() vs foo() etc

2001-04-13 Thread Dave Storrs
On Thu, 12 Apr 2001, Dan Sugalski wrote: > I think Perl_ and maybe Perl__ would be fine. I'd rather Perl_ and _Perl_, > but... How about PerlF_ and PerlD_ (for Functions and Data)? To also specify Exported and Private we could have PerlFE_, PerlFP, etc.

Re: Perl_foo() vs foo() etc

2001-04-13 Thread Kai Henningsen
[EMAIL PROTECTED] (Dan Sugalski) wrote on 12.04.01 in <[EMAIL PROTECTED]>: > At 12:16 AM 4/13/2001 +0200, Kai Henningsen wrote: > >[EMAIL PROTECTED] (Dan Sugalski) wrote on 11.04.01 in > ><[EMAIL PROTECTED]>: > > > > > *) All private routines have #defines to give them a _Perl_ prefix > > > *)

Re: Perl_foo() vs foo() etc

2001-04-12 Thread Hong Zhang
>IIRC, ISO C says you cannot have /^_[A-Z_][A-Za-z_0-9]*$/. That's reserved >for the standard. If you consider our prefix is "_Perl_" not just "_", we will be pretty safe. There are just not many people follow the standard anyway :-) Hong

Re: Perl_foo() vs foo() etc

2001-04-12 Thread Brent Dax
Dan Sugalski wrote on 4/11/01 13.38: >At 03:09 PM 4/11/2001 >-0400, John Siracusa wrote: >>On 4/11/01 10:55 AM, Dan >Sugalski wrote: >> > 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

Re: Perl_foo() vs foo() etc

2001-04-12 Thread Dan Sugalski
At 12:16 AM 4/13/2001 +0200, Kai Henningsen wrote: >[EMAIL PROTECTED] (Dan Sugalski) wrote on 11.04.01 in ><[EMAIL PROTECTED]>: > > > *) All private routines have #defines to give them a _Perl_ prefix > > *) All private data have #defines to give them a _PL_ prefix > >IIRC, ISO C says you cannot

Re: Perl_foo() vs foo() etc

2001-04-12 Thread Kai Henningsen
[EMAIL PROTECTED] (Dan Sugalski) wrote on 11.04.01 in <[EMAIL PROTECTED]>: > *) All private routines have #defines to give them a _Perl_ prefix > *) All private data have #defines to give them a _PL_ prefix IIRC, ISO C says you cannot have /^_[A-Z_][A-Za-z_0-9]*$/. That's reserved for the st

Re: Perl_foo() vs foo() etc

2001-04-11 Thread Dan Sugalski
At 03:47 PM 4/11/2001 -0500, Jarkko Hietaniemi wrote: >On Wed, Apr 11, 2001 at 04:38:21PM -0400, Dan Sugalski wrote: > > At 03:09 PM 4/11/2001 -0400, John Siracusa wrote: > > >On 4/11/01 10:55 AM, Dan Sugalski wrote: > > > > It does fix the link issues, though. perl6.so won't ever have an > > > >

Re: Perl_foo() vs foo() etc

2001-04-11 Thread John Siracusa
On 4/11/01 4:38 PM, Dan Sugalski wrote: > At 03:09 PM 4/11/2001 -0400, John Siracusa wrote: >> On 4/11/01 10:55 AM, Dan Sugalski wrote: >>> 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,

Re: Perl_foo() vs foo() etc

2001-04-11 Thread Jarkko Hietaniemi
On Wed, Apr 11, 2001 at 04:38:21PM -0400, Dan Sugalski wrote: > At 03:09 PM 4/11/2001 -0400, John Siracusa wrote: > >On 4/11/01 10:55 AM, Dan Sugalski wrote: > > > 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

Re: Perl_foo() vs foo() etc

2001-04-11 Thread Dan Sugalski
At 03:09 PM 4/11/2001 -0400, John Siracusa wrote: >On 4/11/01 10:55 AM, Dan Sugalski wrote: > > 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

Re: Perl_foo() vs foo() etc

2001-04-11 Thread John Siracusa
On 4/11/01 10:55 AM, Dan Sugalski wrote: > 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. Remind me again why it's PL_ and not PERL_? It s

Re: Perl_foo() vs foo() etc

2001-04-11 Thread Dan Sugalski
At 12:05 PM 4/11/2001 -0400, Andy Dougherty wrote: >On Wed, 11 Apr 2001, Dan Sugalski wrote: > > > 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 export

Re: Perl_foo() vs foo() etc

2001-04-11 Thread Andy Dougherty
On Wed, 11 Apr 2001, Dan Sugalski wrote: > 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. Ah, ok. That's a change from perl5 practi

Re: Perl_foo() vs foo() etc

2001-04-11 Thread Dan Sugalski
At 11:00 AM 4/11/2001 -0400, Bryan C. Warnock wrote: >Okay, I *really* may have missed something > >Do you mean this: > >/* Allow us to refer to _Perl_foo() as just foo() inside */ >#define _Perl_foo foo > >or this: > >/* We're foo(), other folks can call us _Perl_foo() */ >#define foo _Perl_f

Re: Perl_foo() vs foo() etc

2001-04-11 Thread Bryan C. Warnock
Okay, I *really* may have missed something Do you mean this: /* Allow us to refer to _Perl_foo() as just foo() inside */ #define _Perl_foo foo or this: /* We're foo(), other folks can call us _Perl_foo() */ #define foo _Perl_foo The second is what I read from your list, although the first

Re: Perl_foo() vs foo() etc

2001-04-11 Thread Dan Sugalski
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, th

Re: Perl_foo() vs foo() etc

2001-04-11 Thread Dan Sugalski
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

Re: Perl_foo() vs foo() etc

2001-04-11 Thread Bryan C. Warnock
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? This isn't to bypass the 'leading underscore' reservation, is it? On Wednesday 11 Apri

Re: Perl_foo() vs foo() etc

2001-04-11 Thread Andy Dougherty
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

Re: Perl_foo() vs foo() etc

2001-04-11 Thread Dan Sugalski
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 >con

Perl_foo() vs foo() etc

2001-04-11 Thread Dave Mitchell
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