On Sat, Sep 16, 2000 at 11:08:18AM +1100, Jeremy Howard wrote:
proposes a convenient syntax to slice multi-dimensional arrays;
It is hard to evaluate this proposal without more context. In particular:
- How does it relate to RFC 204? Is it an alternative, or an addition?
204 cannot be
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
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
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 that a
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) does not
[ 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
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]
Perl6 RFC Librarian wrote:
The effects of applying Cprivate to a single hash entry would be to:
=over 4
=item 1.
mark the entire hash as non-autovivifying (except via future calls to
Cprivate -- see below)
This is an interesting proposal, but it seems to be missing something, or maybe I
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
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: 73
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:
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]
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 strict
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 arrays in a
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
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
On Fri, Sep 15, 2000 at 03:11:47PM -0600, Nathan Torkington wrote:
Perl6 RFC Librarian writes:
This RFC proposes two-stage autoloading: one stage may be registered
to act when the symbol is encountered at compile time, the other
when the subroutine is called. Autoloading on the second
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 layers of
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 Cfoo-bar $baz to write this
method call is as convenient as the indirect object syntax, the proposal
is to
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 requires
=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 pain
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()) and
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.
I
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 { ... };
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
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
Replace Cformat built-in with pragmatically-induced Cformat function
This RFC proposes that Perl's existing Cformat 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
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: 2
Status:
${$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
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 chop() a lot and
No overloading of f($arg) basing on ref($arg)
There are several proposals to switch the meaning of Cf($arg) 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
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, because
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 something
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:
print
=head1 VERSION
Maintainer: Michael Schwern [EMAIL PROTECTED]
Date: 16 September 2000
Mailing List: perl6-language
Number: ?
Version: 1
Status: Developing (Last Call)
Reply-To: perl6-language @perl.org
This and other RFCs are available on the web at
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
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: 1
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
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add new Cempty 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
40 matches
Mail list logo
