> =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
True Polymorphic Objects
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last-Modified: 16 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 159
Version: 2
Status:
On Sun, Sep 17, 2000 at 11:07:09AM +1100, Jeremy Howard wrote:
> > I repeat: what does
> >
> > $a[ $ind ]
> >
> > does if $ind is a (blessed) reference to array (1,1), but behaves as
> > if it were 11 (due to overloading)?
> >
> How $ind is implemented (ie the actual structure that is blessed)
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
All Perl core functions should return objects
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last-Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 7
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interpolation of object method calls
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Last Modified: 17 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 222
Ver
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Generalize =~ to a special "apply-to" assignment operator
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 29 Aug 2000
Last-Modified: 16 Sep 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Embed full URI support into Perl
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Last-Modified: 16 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 100
Version: 2
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Modify open() to support FileObjects and Extensibility
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Numbe
[ for those on -all or -objects this is gonna look real familiar :-) ]
All-
As Nat has mentioned on -meta, it's time to start wrapping things up. In
particular, I think the following "deadlines" should apply:
1. Any and all *new* RFC's should be submitted by Wednesday at the
absolute l
All-
As Nat has mentioned on -meta, it's time to start wrapping things up. In
particular, I think the following "deadlines" should apply:
1. Any and all *new* RFC's should be submitted by Wednesday at the
absolute latest (preferably sooner).
2. All existing RFC's should have their f
Ilya Zakharevich wrote:
> On Sat, Sep 16, 2000 at 07:15:34PM +1100, Jeremy Howard wrote:
> > Why is it important for overloaded objects to be used as array indices?
>
> Overloaded objects should behave the same way as non-objects.
>
> > Why
> > does RFC 204 rule that out? RFC 204 simply specifies
>> 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 07:15:34PM +1100, Jeremy Howard wrote:
> Why is it important for overloaded objects to be used as array indices?
Overloaded objects should behave the same way as non-objects.
> Why
> does RFC 204 rule that out? RFC 204 simply specifies that a list reference
> as an index
> Standardize ALL Perl platforms on UNIX epoch
I've seen lots of discussion on this, and there have been 2 previous
versions worth of discussion as well. The first version of this was
actually entitled:
"Maintain internal time in Modified Julian (not epoch)"
but that got shot down so fast it
On Sat, 16 Sep 2000 16:19:08 +0100, Hildo Biersma wrote:
>> But using arrays in a scalar context usually isn't an error.
>
>So, we make the warnings smarter and make sure they can be turned off...
And distinguish between simply an array in scalar context, and an array
used as an argument for len
On Sat, 16 Sep 2000 09:39:28 -0700, Nathan Wiger wrote:
>But not:
>
> no strict 'refs';# on by default, disable
> use strict 'vars';
>
>Which is too confusing.
I wonder if 'strict' shouldn't be turned into 2 or 3 separate pragma's,
instead of just one. IMO, there isn't a strong between str
Michael G Schwern wrote:
>
> I'm surprised there hasn't be a good overhaul of the prototyping
> system proposeed yet. Your length() propsal wouldn't be the only
> think that can't be prototyped. print() is the simplest example.
I think print should probably become something like what Eryq sugg
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-
> Yet, I personally would prefer it if strict 'refs' is always on by
> default. Would this hinder one-liners? How many one-lliners do you write
> that depend on symbolic references? None, I hope.
The problem with this is that now we're only turning some strictness on,
like turning some warnings o
> 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.
Bart Lateur wrote:
>
> On Sat, 16 Sep 2000 10:26:48 +0100, Hildo Biersma wrote:
>
> >> length(@ary) deserves a warning
> >
> >Right now, the Lint back-end gives a warning in these cases (use of
> >array in scalar context).
> >
> >Can we make the RFC more generic, and propose to move the Lint war
On Sat, 16 Sep 2000 10:26:48 +0100, Hildo Biersma wrote:
>> length(@ary) deserves a warning
>
>Right now, the Lint back-end gives a warning in these cases (use of
>array in scalar context).
>
>Can we make the RFC more generic, and propose to move the Lint warnings
>into the core?
But using array
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
>
> This RFC proposes a minimal efficient well-scaling mechanism for
exporting.
> Only export of subroutines and tags are supported by this mechanism.
>
Though I'm not completely sure how the implementation works in other
compiled languages, I rather like the C, Java, Python method where just
abo
> =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
> =head1 TITLE
>
> length(@ary) deserves a warning
Right now, the Lint back-end gives a warning in these cases (use of
array in scalar context).
Can we make the RFC more generic, and propose to move the Lint warnings
into the core?
Hildo
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 16 Sep 2000 03:12:06 -, Perl6 RFC Librarian wrote:
>The only major change to the text of this RFC was to remove a paragraph
>stating that this RFC is particularly targeted to keep C
>off by default.
Yet, I personally would prefer it if strict 'refs' is always on by
default. Would this hin
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
Ilya Zakharevich wrote:
> On Sat, Sep 16, 2000 at 11:08:18AM +1100, Jeremy Howard wrote:
> > - How does it relate to RFC 204? Is it an alternative, or an addition?
>
> 204 cannot be implemented since it prohibits usage of overloaded
> objects as array indices.
>
Why is it important for overloaded
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
Perl6 RFC Librarian wrote:
> The effects of applying C to a single hash entry would be to:
>
> =over 4
>
> =item 1.
>
> mark the entire hash as non-autovivifying (except via future calls to
> C -- see below)
This is an interesting proposal, but it seems to be missing something, or maybe I
am. I
41 matches
Mail list logo
