James Mastros wrote:
>
> As far as setting|getting, I'd like to make a simple proposal. Consider it
> an idea for whoever writes the RFC (I'm looking at you, Nate)
Oh, jeez, as if I didn't have enough already! ;-)
> The idea is this: every variable should have a psudohash of attributes.
Idea
Alan Gutierrez wrote:
>
> This header functionality is application specific and does not belong in
> the core any more than the socket stuff which seems to be on its way
> out. I don't see why this has be implemented in the core in C.
>
> Once again, if core means core modules, and as a part of
I tried to contribute on this list but it seems we've coalesced downto Tom
and a handful of others. No one else has a voice.
I have nothing but respect for Tom, Nathan, et al, but its no longer my idea
of a community - more like a faction. I'm getting more into PHP now and
less into Perl, onl
On Wed, 27 Sep 2000, Adam Turoff wrote:
> On Wed, Sep 27, 2000 at 11:33:13AM -0700, Nathan Wiger wrote:
> > Ziggy, are you interested in this idea enough (at all?) to stick a note
> > about the 'header' function into the RFC? Or should I RFC it separately?
>
> Adding headers() to the core langua
On Wed, 27 Sep 2000, Nathan Wiger wrote:
> Robert Mathews wrote:
> > How are you going to handle multiple values for the same parameter?
> > With CGI.pm, you can say
> > @values = $q->param("foo");
>
> 2. make it a comma-delimited string:
>
>$name = $CGI{name};
>@name = split ',', $
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
with takes a context
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 28 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 340
Version: 1
Status: Developing
=head1 ABSTRACT
"cal
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
caller->eval BLOCK
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 28 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 339
Version: 1
Status: Developing
=head1 ABSTRACT
C is e
There are many (good) RFCs that specify new attributes. To the best of my
knowledge, there is no good RFC discussing how to go about making
attributes, setting them, and getting them.
As far as setting|getting, I'd like to make a simple proposal. Consider it
an idea for whoever writes the RFC (
> PS> un is such a lame prefix and very un perl like... unjoin? unpush?
> okay so unshift, but still... hey wait I want undelete!
Heh. :-) This is not really true, in fact within Perl it is the One True
Prefix, ala undef, unlink, unpack, unshift, untie...
-Nate
Jonathan Scott Duff wrote:
>
> My first thought was "this should definitely be in a module" and your
> comments just fire those synapses even more strongly.
Yes, this will likely end up in a core module. The main thing is that it
always has to be available so that pragmas like "use cgi" can impo
Personally I think this is probably a bad idea.
But if such a thing WERE to be implemented, I don't see why you have to have
two words...
header(a>1, b=>2); #options list, returns a string with formatted headers
header($foo); #scalar option $foo is parsed and a list is returned
John Porter wrote:
>
> David L. Nicol wrote:
> >
> >
> > print "Found It at position ${_:n}!\n" if /$seek/ foreach @items
>
> If we are going to be throwing around attributes like that, why
> don't we switch to using the ubiquitously recognizable dot instead
> of colon?
>
> for my
David L. Nicol wrote:
>
>
> print "Found It at position ${_:n}!\n" if /$seek/ foreach @items
If we are going to be throwing around attributes like that, why
don't we switch to using the ubiquitously recognizable dot instead
of colon?
for my $iter ( @things ) {
pri
On Thu, Sep 28, 2000 at 03:22:08PM -0600, John Barnette wrote:
> Perl6 RFC Librarian (Today):
> > =head1 TITLE
> > Add C and C funtions to core distribution
>
> While I'm not sure if this belongs in the core or not, I think it's nifty,
> and I'd like to point out an almost inevitable side effect.
I think the octal number representation should not be accepted...
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
Perl6 RFC Librarian (Today):
> =head1 TITLE
> Add C and C funtions to core distribution
>Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
>
> =head1 ABSTRACT
> This RFC proposes that Perl include a simple function, C, that
> can be used to interact with these headers more easily. It is a
> gener
On Thu, Sep 28, 2000 at 12:25:32PM +0100, Tom Christiansen wrote:
> You also didn't mention that you would have broken the symmetry between
>
>my Dog $spot;
>our Dog $spot;
No, I didn't mention our Dog $spot should be the same thing, but on an our
variable.
> Or that constructors h
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add C and C funtions to core distribution
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 27 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 333
Version: 1
Status: Devel
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
C
=head1 VERSION
Maintainer: Simon Cozens <[EMAIL PROTECTED]>
Date: 28 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 329
Version: 1
Status: Developing
=head1 ABSTRACT
A pragma to modify the
Simon Cozens wrote:
>
> On Thu, Sep 28, 2000 at 10:00:49AM -0400, Andy Dougherty wrote:
> > On Wed, 27 Sep 2000, Nathan Wiger wrote:
> > > Y'know, I couldn't have said this better myself. :-) I've always felt
> > > that "use English" was a waste of time and effort, a bandaid trying to
> > > act a
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Method calls SHOULD suffer from ambiguity by default
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 24 Sep 2000
Last Modified: 28 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number
On Thu, Sep 28, 2000 at 02:40:04PM -0400, John Porter wrote:
> Tom Christiansen wrote:
> > Perl's use of @ISA is beautiful.
> >
> > use base is, or can be, pretty silly --
> > think pseudohashes, just for one.
>
> I suppose you diddle @INC directly, Tom,
> instead of use'ing lib?
I call "non
On Thu, Sep 28, 2000 at 08:06:42AM +0200, H . Merijn Brand wrote:
> On 27 Sep 2000 07:36:42 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> > This and other RFCs are available on the web at
> > http://dev.perl.org/rfc/
> >
> > =head1 TITLE
> >
> > First-Class CGI Support
>
> Freezing
Andy Dougherty <[EMAIL PROTECTED]> writes:
> I find that I don't remember many of the less-frequently-used perlvars
> (where less-frequently-used depends on the types of programs I write,
> obviously). I certainly couldn't tell you off-hand the differences
> among $< $> $( and $). I'd have to l
Jonathan Scott Duff wrote:
>
> 1. Allow the first argument to split() to be a number such that
>the string is broken into chunks of that many characters.
@strings = /(.{$n})/g;
> 2. Allow the first argument to split() to be an array of
>numbers, such t
Tom Christiansen wrote:
>
> Perl's use of @ISA is beautiful.
>
> use base is, or can be, pretty silly --
> think pseudohashes, just for one.
I suppose you diddle @INC directly, Tom,
instead of use'ing lib?
--
John Porter
Nathan Wiger wrote:
> 1. make a listref only for multiple values:
>@name = @{$CGI{name}} if ( ref $CGI{name} eq 'ARRAY' );
Ick. That piece of code is small enough, but it's going to end up
replicating itself everywhere %CGI is accessed. This will be a fruitful
new source of bugs when people
On Thu, Sep 28, 2000 at 01:02:11PM -0500, Jonathan Scott Duff wrote:
> I thought I had sent this the other day, but it doesn't appear to have
> made it through...
>
> Here are a couple of ideas that I don't have time to RFC, but some who
> likes them might:
>
> 1. Allow the first argumen
I thought I had sent this the other day, but it doesn't appear to have
made it through...
Here are a couple of ideas that I don't have time to RFC, but some who
likes them might:
1. Allow the first argument to split() to be a number such that
the string is broken into chunks o
Buddha Buck wrote:
>
> While Perl -lets- every function be well prototyped, it doesn't -require-
> every function to be well prototyped. Because of this, it might be well
> nigh impossible to eliminate all ambiguity to the compiler.
Well, right. Clearly, in those cases, you can expect to nee
On Thu, 28 Sep 2000, Steve Fink wrote:
> Tom Christiansen wrote:
> >
> > As we sneak under the wire here, I'm hoping someone
> > has posted an RFC that alters the meaning of my/local.
> > It's very hard to explain as is. my is fine, but local
> > should be changed to something like "temporary" (
Tom Christiansen wrote:
>
> As we sneak under the wire here, I'm hoping someone
> has posted an RFC that alters the meaning of my/local.
> It's very hard to explain as is. my is fine, but local
> should be changed to something like "temporary" (yes, that
> is supposed to be annoying to type) or
Webmaster wrote:
>
> (I have attached a prototype of what I had in mind)
>
> From: "David L. Nicol" <[EMAIL PROTECTED]>
> > Yes, that is exactly what is being suggested, but the "indexof" function
> > is implicit in the attribute. Your code becomes
> >
> > print "Found It at position ${_:n}!\n"
On Thu, Sep 28, 2000 at 10:00:49AM -0400, Andy Dougherty wrote:
> On Wed, 27 Sep 2000, Nathan Wiger wrote:
> > Y'know, I couldn't have said this better myself. :-) I've always felt
> > that "use English" was a waste of time and effort, a bandaid trying to
> > act as a tourniquet.
>
> I think it's
> A future protocol could well require things in order. Hence you're
> having the output headers in order. Therefore you should have the input
> ones available in order as well.
I don't see a reason why an @HTTP ordered and %HTTP unordered couldn't
both be supported.
> I'm thinking a $headers_i
Tom Christiansen wrote:
>
> >So what's left?
> >
> >print STDERR "Foo";
> >
> >We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go
> >through.
>
> It is? I certainly hope not. It makes as much sense to
> do that as to force a dollar sign on subroutines.
Your point
Piers Cawley wrote:
>
> > >I strongly agree with the opinion that we should try and get away from
> > >special variables and switches in favor of functions and pragmas.
> > >Witness 'use base' instead of '@ISA', 'use warnings', and so on.
> >
> > Huh? Why??? Perl's use of @ISA is beautiful. It
On Wed, 27 Sep 2000, Nathan Wiger wrote:
> Russ Allbery wrote:
> >
> > I've found the use of use English in code I had to maintain to be annoying
> > and unhelpful, and to actually degrade the maintainability of the code
> Y'know, I couldn't have said this better myself. :-) I've always felt
> t
Certainly numbers should never be "zero-padded"!
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
You also didn't mention that you would have broken the symmetry between
my Dog $spot;
our Dog $spot;
Or that constructors have no (and should have no) set name in Perl.
--tom
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >I strongly agree with the opinion that we should try and get away from
> >special variables and switches in favor of functions and pragmas.
> >Witness 'use base' instead of '@ISA', 'use warnings', and so on.
>
> Huh? Why??? Perl's use of @ISA is
* Philip Newton ([EMAIL PROTECTED]) [28 Sep 2000 21:19]:
> On 27 Sep 2000, at 23:48, iain truskett wrote:
> > So surely you'd want %HTTP (the input headers) to also be an array
> > rather than a hash, since they'd be required in order as well?
> I don't care, because I don't work with this much.
On 27 Sep 2000, at 23:48, iain truskett wrote:
> So surely you'd want %HTTP (the input headers) to also be an array
> rather than a hash, since they'd be required in order as well?
I don't care, because I don't work with this much. And I don't know
whether I'd need to bear in mind the protocol
To my mind, things would be a lot clearer if my and local were to change
places - but I can see why that would not be a good thing.
If it's not too late for suggestions for renaming local, what about
'override'.
Dave.
- Original Message -
From: "Michael Fowler" <[EMAIL PROTECTED]>
To: "T
On Thu, Sep 28, 2000 at 10:18:34AM +0100, Tom Christiansen wrote:
> As we sneak under the wire here, I'm hoping someone
> has posted an RFC that alters the meaning of my/local.
> It's very hard to explain as is. my is fine, but local
> should be changed to something like "temporary" (yes, that
>
>So what's left?
>
>print STDERR "Foo";
>
>We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go
>through.
It is? I certainly hope not. It makes as much sense to
do that as to force a dollar sign on subroutines.
sub $foo { ... }
or
sub 'foo' { ... }
Heck,
>I strongly agree with the opinion that we should try and get away from
>special variables and switches in favor of functions and pragmas.
>Witness 'use base' instead of '@ISA', 'use warnings', and so on.
Huh? Why??? Perl's use of @ISA is beautiful. It's an example
of code reuse, because we do
Try thinking of it this way: it's only a bareword if
it would make use strict whinge at you. Thus, the
constructs you cited are all non-uses of barewords,
such as in use Foo or require Foo or Foo => 1, or
even $x{Foo}. And I have proposed (nonRFC) that
Foo->bar() also be not a bareword. Yes, I
As we sneak under the wire here, I'm hoping someone
has posted an RFC that alters the meaning of my/local.
It's very hard to explain as is. my is fine, but local
should be changed to something like "temporary" (yes, that
is supposed to be annoying to type) or "dynamic".
Visit our website at http
John Porter <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
> >
> > You know, I'm trying to see what's annoying about all those
> > parentheses in the lisp function and what do you know, I can't see
> > anything wrong. Okay, so it's not Perl syntax, but it's still clear
> > what's going on.
>
This RFC still has silly language that discounts what
has been said before.
1) It calls
uc($a) eq uc($b)
"ugly", despite their being completely intuitive and legible
to even the uninitiated.
2) It then proposes "eq/i" without the least blush, despite
how incredibly ugly and non-intu
Adam Turoff wrote:
>
> On Wed, Sep 27, 2000 at 11:33:13AM -0700, Nathan Wiger wrote:
> > Ziggy, are you interested in this idea enough (at all?) to stick a note
> > about the 'header' function into the RFC? Or should I RFC it separately?
>
> Adding headers() to the core language (or a similar pr
52 matches
Mail list logo
