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
Greg Boug wrote:
> use lib "CPAN::HTML::Module";
> which goes and grabs the module in question from CPAN for
> use. Picking, the closest mirror, of course.
We should not attempt to resurrect this poor dead horse,
only to beat it to death again. See the perl6-language archives.
> you could ope
Damian Conway <[EMAIL PROTECTED]> writes:
>> Of course all of this has been discussed. (See
>> http://archive.develooper.com/perl6-language-io%40perl.org/,
>> especially RFCs 100 and 14.)
>
> And is already available in a nearby parallel dimension:
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 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
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 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
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
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
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
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
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 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 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
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,
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
> > > >
Dan Sugalski wrote:
> At 09:40 PM 4/6/2001 +0100, Richard Proctor wrote:
> >On Fri 06 Apr, Dan Sugalski wrote:
> > > This is, I presume, in addition to any sort of inherent DWIMmery? I
don't
> > > see any reason that:
> > >
> > > @foo[1,2] = ;
> > >
> > > shouldn't read just two lines from tha
18 matches
Mail list logo
