> =head1 REFERENCES
>
> http://www.mail-archive.com/perl6-language@perl.org/msg03703.html
>
> And a previous, humorous yet poignant one from Tom C which appears to
> have vanished
That would be his s/undef/uninitialize/ suggestion.
http://www.mail-archive.com/perl-qa@perl.org/msg00184.html
--
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add new C keyword to DWIM for clearing values
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 16 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 245
Version: 1
Status: D
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Formats out of core / New format syntax
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 30 Aug 2000
Last Modified: 16 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 181
Versi
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Remove "In string @ must be \@" fatal error
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 15 Aug 2000
Last-Modified: 16 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 105
V
On Sat, Sep 16, 2000 at 07:26:38PM -0700, Nathan Wiger wrote:
> My point was more should that be
>
>'Class'->name
>
> or
>
>Class()->name
I don't get it, lemme start from the beginning:
print "Basset hounds got long Basset::Hounds->thang().";
I'd like that to work out as:
p
Michael G Schwern wrote:
>
> >print "Your name is Class->name";
> >
> > Whether Class is 'Class' or Class(). The phrase "avoid at all costs"
> > comes to mind. ;-)
>
> Hmmm... we could require that the trailing parens be there:
>
> print "Your name is Class->name()";
Right, we could do
On Sat, Sep 16, 2000 at 02:57:01PM -0700, Nathan Wiger wrote:
> > Ooop, didn't even notice and didn't see the discussion. Let me see if
> > I missed anything... I didn't discuss class methods as opposed to
> > object methods. Will ponder.
>
> It's really dicey. I think it's probably bad, becaus
> No overloading of f($arg) basing on ref($arg)
> There are several proposals to switch the meaning of C basing on
> the whether $arg is an array reference or not. For example, it is tempting
> to allow C<$array[[2,3]]> denote the same as C<$array[2][3]>.
Ilya-
I know I'd personally appreciate
>> Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
>> Date: 5 Sep 2000
>> Last Modified: 15 Sep 2000
>> Mailing List: [EMAIL PROTECTED]
>> Number: 195
>> Version: 2
>> Status: Frozen
>As I mailed to Nathan Torkington several days ago (without getting
>a reply), many people use ch
> ${$pkg.'::'.$var} = $val;
> ${"$pkg\::$var} = $val;
>
> Still ugly, but not quite as bad as what you came up with.
Thanks - once I saw the first one my brain went "Oh, yeah"
> Ooop, didn't even notice and didn't see the discussion. Let me see if
> I missed anything... I didn't
On Sat, Sep 16, 2000 at 03:28:26AM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Retire chop().
>
> =head1 VERSION
>
> Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
> Date: 5 Sep 2000
> Last Modified: 15 Sep 2000
> Mailing List: [EMAIL PROTECTED]
> Number: 195
> Version:
> Replace C built-in with pragmatically-induced C function
> This RFC proposes that Perl's existing C mechanism be replaced
> with a standard module based on parts of the Text::Autoformat module.
One other little thing: I really think this should be
use Format; # like 'use Socket' and 'u
On Sat, Sep 16, 2000 at 09:18:05AM -0700, Nathan Wiger wrote:
> "use D'oh" will be missed :-), but sometimes legacy stuff needs to be
> expunged to get people to modernize.
Of all the legacy things which get abused, this is the one
I've never seen.
> Plus, ' is already widely-used as a single-
> This RFC proposes to remove indirect object syntax
Please show me how to write:
print STDERR @stuff;
without it, while keeping it a method of the STDERR filehandle, and
without requiring ->.
-Nate
> No special UPPERCASE_NAME subroutines
Whoa! What about ALLCAPS variables? Should we axe all of them as well?
They're the exact same idea.
> If some special action handler needs to be registered, this should be
> done not by using a special name, but by a pragma.
>
> use tie STORE => sub { .
> > Perl used to use $pkg'var instead of the modern $pkg::var. This is still
> > in Perl 5. It's gotta go.
>
> Aside from "its old", is there any particular reason why $pkg'var
> should go?
"use D'oh" will be missed :-), but sometimes legacy stuff needs to be
expunged to get people to modernize.
On Sat, Sep 16, 2000 at 10:31:55AM +0100, Hildo Biersma wrote:
> AFAIK, most of the pain in the implementation is caused because any old
> array can be 'promoted' into a pseduo-hash at any-time. If
> pseudo-hashes always have to be pre-declared (eg, can only be created
> through fields::new()) an
> =head1 ABSTRACT
>
> Pseudo-hashes and the associated fields pragma shoule be removed from
> Perl 6.
A few counter points:
Removal of pseudo-hashes should not stop us from using this (or a
similar mechanism) under the covers in perl6 to implement strongly typed
objects.
AFAIK, most of the pai
Nathan Wiger wrote:
>
> > I think such modules are a bad idea, because their functionality is
> > typically restricted.
>
> What, you mean like CGI.pm ?! :-)
Yes, restricted. If you use the procedural interface to a module that
supports both OO and procedural interfaces, you're basically at th
John Porter wrote:
>
> Hildo Biersma wrote:
> >
> > I think such modules are a bad idea, because their functionality is
> > typically restricted.
>
> Oh? Where do you get that idea?
Think about it. If a module supports both an OO and a procedural
interface, the procedural interface either requ
On Sat, Sep 16, 2000 at 08:08:06AM -, Perl6 RFC Librarian wrote:
> There only way to avoid the action at a distance is to prohibit one of these
> interpretations. Since the other way C> to write this
> method call is as convenient as the indirect object syntax, the proposal
> is to
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Method calls should not suffer from the action on a distance
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 244
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
No special UPPERCASE_NAME subroutines
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 243
Version: 1
Status: Developing
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
No overloading of f($arg) basing on ref($arg)
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 242
Version: 1
Status: Dev
On Sat, Sep 16, 2000 at 03:36:45AM -, Perl6 RFC Librarian wrote:
> The current method in which C<__WARN__> and C<__DIE__> signal handlers are
> used is limited in 2ways:
>
> =over 8
>
> =item It does not allow them to accept robust parameter lists.
>
> =item It does not allow for multiple l
25 matches
Mail list logo
