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
> "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
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
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
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
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
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.
[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
> > > *)
>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
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
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
[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
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
> > > >
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
27 matches
Mail list logo
