This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: @#arr for getting the dimensions of an array
=head1 VERSION
Maintainer: Buddha Buck <[EMAIL PROTECTED]>
Date: 8 Sep 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Arrays: Use list reference for multidimensional array access
=head1 VERSION
Maintainer: Buddha Buck <[EMAIL PROTECTED]>
Date: 8 Sep 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED
On Tue, Sep 19, 2000 at 07:17:20PM -0700, Nathan Wiger wrote:
> > ==
> > Either way I'm not sure it solves the problem; if each module asserts
> > that *they* are the smarter one then you either wind up with the same
> > situation you
> ==
> Either way I'm not sure it solves the problem; if each module asserts
> that *they* are the smarter one then you either wind up with the same
> situation you have now or even worse contention.
>
==
What if both modules have this :override bit set at the same time?
Does the second one still win? Or does the first one win again?
==
It is wise to live the behaviour
On Tue, Sep 19, 2000 at 08:41:34AM +1200, Christian Soeller wrote:
> > Finally as an overload expert what do you think about the proposals
> > to make arrays overloadable objects so one can say things like:
> >
> > @x = 3 * @y;
>
> Is this where RFC 231's suggestion for OO slicing comes in (see
On Mon, Sep 18, 2000 at 08:56:28AM -0400, Karl Glazebrook wrote:
> Firstly does your proposal allow for a slice like 10..20:2 (i.e. with
> a stride of 2) ?
As shipped: no. But if this is made a primitive (which I would not
like), then the only change which is needed is to make the
tie::multi::r
On Mon, Sep 18, 2000 at 02:31:10PM -0400, Chaim Frenkel wrote:
> How about a Base64 to match with uuencode?
> PRL> This RFC proposes simple enhancements to templates of pack/unpack builtins.
> PRL> These enhancements do not change the spirit of how pack/unpack is used.
> PRL> The semantic is enha
Unless I hear otherwise, I plan on freezing RFC 204 and RFC 206 this
evening (17:30 New York time), and issue a revised version of 207. The
frozen versions will be substantially identical to the versions ow
released.
On RFC 204 (LOL refs as indices), I have followed the discussion from
Ilya
