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
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
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 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
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
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
18 matches
Mail list logo
