Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Objects: C pragma
>
> =head1 VERSION
>
> Maintainer: Damian Conway <[EMAIL PROTECTED]>
> Date: 14 September 2000
> Mailing List: [EMAIL PRO
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> 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: 1
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data types: Semi-finite (lazy) lists
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 24
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Control flow: Builtin switch statement
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 22
Version
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Operators: Multiway comparisons
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 25
Version: 2
S
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Higher order functions
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 18 Sep 2000
Number: 23
Version: 5
Mailing List: [EMAIL PROTECTED]
Status: Fr
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines: Co-routines
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 18 Sep 2000
Number: 31
Version: 2
Mailing List: [EMAIL PROTECTED]
Status:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Request For New Pragma: Shell
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 42
Version: 3
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Operators: Polymorphic comparisons
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 7 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 54
Version: 2
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Compilation: Remove requirement for final true value in require-d and do-ed files
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 7 Aug 2000
Last Modified: 18 Sep 2000
Mailing Lis
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow exception-based error-reporting.
=head1 VERSION
Maintainer: Bennett Todd <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 70
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace => (stringifying comma) with => (pair constructor)
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 10 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Regex: Support for incremental pattern matching
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 11 Aug 2000
Last Modified: 18 Sep 2000
Number: 93
Version: 3
Mailing List: [EMA
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Overview: Perl OO should I be fundamentally changed.
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 21 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Numbe
=head1 VERSION
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add reshape() for multi-dimensional array reshaping
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Last Modi
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Retire chop().
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: 5 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 195
Version: 3
Status: Froze
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data: Superpositions
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 225
Version: 2
Status: Fr
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace C built-in with pragmatically-induced C function
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
N
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Fix iteration of nested hashes
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 255
Version: 1
Status: Developing
=head1 A
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Mandatory and enhanced second argument to C
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Numbe
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Rationalizing C, C, and C
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 224
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : NEXT pseudoclass for method redispatch
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 19
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Hierarchical calls to initializers and destructors
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
UNIVERSAL::import()
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 257
Version: 1
Status: Developing
=head1 ABSTRACT
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Native support for multimethods
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 18 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 256
Version: 1
Status: Deve
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add memoize into the standard library
=head1 VERSION
Maintainer: Adam Turoff <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 228
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Extend the window to turn on taint mode
=head1 VERSION
Maintainer: Adam Turoff <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 227
Versio
On Thu, 14 Sep 2000 12:41:04 -0700, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> 1) do perl6 formats need to have exactly the same scoping rules as perl5
> formats in this regard?
perl5 formats do NOT support lexicals, so this is not a very interesting
question. (Re-)implementation of formats in
> I'm not going to have time to produce an RFC on this in time for the
> cutoff point. (Which seems painfully soon tbh).
I will be struggling to find the time too. I'll do my best.
Damian
> [From DBI->connect()]
>
> # XXX this is inelegant but practical in the short term, sigh.
> if ($installed_rootclass{$class}) {
> $dbh->{RootClass} = $class;
> bless $dbh => $class.'::db';
> my ($outer, $inner) = DBI::_handles($dbh);
> bless $inner => $cla
Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Thu, Sep 14, 2000 at 02:19:38PM +0100, Piers Cawley wrote:
> > Michael G Schwern <[EMAIL PROTECTED]> writes:
> > > package Dog;
> > > use fields qw(this night up);
> > >
> > > my Dog $ph = [];
> > > $ph->{this} = "that";
> >
> >
Damian Conway <[EMAIL PROTECTED]> writes:
> Piers wrote:
>
>> I'm kind of tempted to look at adding another pragma to go with 'use
>> base' along the lines of:
>>
>> use implements 'Interface';
>>
>> Which is almost entirely like C but with
>> 'Interface' cons
Buddha Buck <[EMAIL PROTECTED]> writes:
> At 08:13 AM 9/15/00 +1100, Damian Conway wrote:
> >Piers wrote:
> >
> >> I'm kind of tempted to look at adding another pragma to go with 'use
> >> base' along the lines of:
> >>
> >> use implements 'Interface';
> >>
> >> Which
On Sun, 17 Sep 2000 21:59:47 -0700, Nathan Wiger wrote:
>Yeah, I for one think %hashes should be interpolated exactly like
>@arrays. It's simple and consistent.
Simple and consistent would be behaviour like
"@{[%hash]}"
However, convenient it is not, getting all key/value pairs in one
Bart Lateur <[EMAIL PROTECTED]> writes:
> 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 i
With the deadline for new RFCs fast approaching I've got a couple or
three RFCs that I won't have time to get properly written in the time
available, and I'm sure I'm not alone.
Therefore, I propose that we be allowed to submit RFC prototypes of
the form:
=head1 TITLE
RFC prototypes
Michael G Schwern wrote:
> On Mon, Sep 18, 2000 at 01:35:42AM -0400, Adam Turoff wrote:
> > Background: RFCs should be in development until frozen or retired.
> >
> > Problem: Frozen RFCs are being updated.
>
> Solution #4: Slip the RFC status back to 'developing'.
>
> If someone updates a frozen
On Mon, 18 Sep 2000 10:57:49 +0200, H.Merijn Brand wrote:
>perl5 formats do NOT support lexicals
Eh? It looks like it, though.
my $foo;
format STDOUT =
@>>>
$foo
.
$foo = 123;
write;
$foo = 45;
write;
It looks *so muc
> > =head1 NOTES ON FREEZE
> >
> > The only comments received were on my crappy examples, which have been
> > clarified. Everyone seemed to like the idea.
>
> Personally I hated it. And I distinctly remember saying so. And I
> still hate it.
I dislike it too. URIs are a user-space matter and sh
Hildo Biersma <[EMAIL PROTECTED]> writes:
> > > =head1 NOTES ON FREEZE
> > >
> > > The only comments received were on my crappy examples, which have been
> > > clarified. Everyone seemed to like the idea.
> >
> > Personally I hated it. And I distinctly remember saying so. And I
> > still hate it
Chaim Frenkel writes:
> What about formating the output as a value that can be used by eval?
>
> %hash = (a => 1, b => 'the world');
> print "%{hash}\n";
>
> ('a' => 1, 'b'=> 'the world')
Interesting.
> And as for having to escape % in printf strings. Why not enable the
> interpola
Hi Ilya,
I have three questions about your RFC:
Firstly does your proposal allow for a slice like 10..20:2 (i.e. with
a stride of 2) ?
If not is there an easy way to incorporate that?
Secondly, what about having multidim support in the core so that the
tie-tokenisers get optimised away? i.e.
>> Oh joy: now Perl has nested quotes. I *hate* nested quotes.
>Those are single-quotes inside double-quotes.
Yep: nested, with varying semantic effects. Completely nasty.
-tom
>It hurts me to do this when there's even a little bit of data, since it
>ends up spanning lines really quickly. And it's harder to read and
>figure out how everything lines up. Honestly, which is easier to read
>and code?
>print "Thanks, ", $q->param('name'), " for your order of ",
>$q->param('a
>So what about
> print "Thanks, $user->{'first name'} for your order!";
>Which needs nested quotes already?
printf() is more readable in such cases.
--tom
>This RFC proposes that rather than three separate mechanisms (in three
>separate namespaces) to determine object typing information, Perl 6
>simply extend the C function to return all the necessary
>information in a list context.
That sounds nice. It would also cure the funny business I tacitly
Leon Brocard <[EMAIL PROTECTED]> writes:
> Dave Storrs sent the following bits through the ether:
>
> > Personally, I like the way it works at the moment; all the subs
> > that you want to memoize are up at the top, where they are easy to see.
> > You can add, subtract, and change the list in a
On Mon, 18 Sep 2000 13:49:25 +0200, Bart Lateur <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Sep 2000 10:57:49 +0200, H.Merijn Brand wrote:
>
> >perl5 formats do NOT support lexicals
>
> Eh? It looks like it, though.
>
> my $foo;
> format STDOUT =
> @>>>
> $foo
> .
>> >perl5 formats do NOT support lexicals
>>
>> Eh? It looks like it, though.
>>
>> my $foo;
>> format STDOUT =
>> @>>>
>> $foo
>> .
>>
>> $foo = 123;
>> write;
>> $foo = 45;
>> write;
>>
>> It looks *so much* that way, that I think you must be
On Mon, 18 Sep 2000 08:43:05 -0600, Tom Christiansen <[EMAIL PROTECTED]> wrote:
> I do not think you two are arguing about the same thing.
>
> Certainly as Bart has shown, formats *can* see lexicals. Your
> illustration does not disprove that. It simply shows that lexical
> scoping is static sc
On 16 Sep 2000, Perl6 RFC Librarian wrote:
> Supercedes: RFC 212
"Supersedes" is usually spelled with an S in the middle. (Compare also
http://www.ietf.org/internet-drafts/draft-ietf-usefor-article-03.txt
[grandson-of-RFC1036], section 6.13, for the spelling; it, too, uses S.)
Cheers,
Philip
>On 16 Sep 2000, Perl6 RFC Librarian wrote:
>> Supercedes: RFC 212
>"Supersedes" is usually spelled with an S in the middle. (Compare also
>http://www.ietf.org/internet-drafts/draft-ietf-usefor-article-03.txt
>[grandson-of-RFC1036], section 6.13, for the spelling; it, too, uses S.)
Must be, i
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
CN> Why? File::Spec is in the core. So are multitudinous
CN> ExtUtils::MM_* modules.
>>
>> Covers the platforms that have perl ports. Your problem requires solutions
>> for platforms that don't have a perl port. (yet :-)
CN> No, you misun
Chris Nandor wrote:
>
> >just assume "All Perl core functions should return objects", and hence
> >the reason I wrote RFC 73. ;-)
>
> And it would make me stop using Perl faster than your object method could
> be resolved.
Is your concern one of?
1. Speed
2. Bloat
3. Excess burden o
Hildo Biersma wrote:
>
> > Personally I hated it. And I distinctly remember saying so. And I
> > still hate it.
>
> I dislike it too. URIs are a user-space matter and should not be
> built-in to the language - put it in a module. And if you have an OS
> that implements URIs directly, well then
On Mon, Sep 18, 2000 at 08:26:26AM -0700, Nathan Wiger wrote:
> Hildo Biersma wrote:
> >
> > > Personally I hated it. And I distinctly remember saying so. And I
> > > still hate it.
> >
> > I dislike it too. URIs are a user-space matter and should not be
> > built-in to the language - put it in
Tom Christiansen wrote:
>
> > * Have to use ugly globref syntax to pass them around reliably.
>
> No, you don't. You can use globs. But only if you don't have
> prototypes, like sub opt(*).
I would argue that many Perlers don't use prototypes.
Whether they should or not is another issu
>As Nate pointed out: print "$hash->{'f'.'oo'}" already works fine and
>the world spins on.
That is no argument for promoting illegibility.
--tom
On Mon, Sep 18, 2000 at 07:30:37AM -0600, Tom Christiansen wrote:
> >So what about
>
> > print "Thanks, $user->{'first name'} for your order!";
>
> >Which needs nested quotes already?
>
> printf() is more readable in such cases.
Okay, we get the idea! Only very simple things should interpol
>Okay, we get the idea! Only very simple things should interpolate.
>Do you have any other objections to the RFCs?
Yes: to the mail volume. And I'm about to fix that.
On Mon, Sep 18, 2000 at 01:01:55PM -0400, John Siracusa wrote:
> Don't forget the fact that direct access is much faster than a method
> call in Perl 5. This will be fixed in Perl 6, of course...right? :)
RFC 163
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Tom Christiansen wrote:
>
> >So what about
>
> > print "Thanks, $user->{'first name'} for your order!";
>
> >Which needs nested quotes already?
>
> printf() is more readable in such cases.
I guess we just have a difference opinion on what consitutes making
things easy.
-Nate
On Mon, Sep 18, 2000 at 09:48:27AM +0100, Piers Cawley wrote:
> Michael G Schwern <[EMAIL PROTECTED]> writes:
> > Nope. fields::new() basically just does C > [\%{"$class\::FIELDS"}], $class>, but the current pseudohash
> > implementation doesn't care if something is an object or not. It just
> >
On 9/18/00 3:44 AM, Damian Conway wrote:
>>> my $weather = new Schwern::Example;
>>> print "Today's weather will be $weather->{temp} degrees and sunny.";
>>> print "And tomorrow we'll be expecting ", $weather->forecast;
>>
>> You are wicked and wrong to have broken inside and peeked at the
On Mon, Sep 18, 2000 at 07:23:41AM -0600, Tom Christiansen wrote:
> >> Oh joy: now Perl has nested quotes. I *hate* nested quotes.
> >Those are single-quotes inside double-quotes.
>
> Yep: nested, with varying semantic effects. Completely nasty.
As Nate pointed out: print "$hash->{'f'.'oo'}"
On 17 Sep 2000 23:54:05 -0400, Chaim Frenkel wrote:
>What about formating the output as a value that can be used by eval?
>
> %hash = (a => 1, b => 'the world');
> print "%{hash}\n";
>
>('a' => 1, 'b'=> 'the world')
So, what about arrays? Or scalars?
We have Data::Dumper for that.
Perl6 RFC Librarian wrote:
> RFC 246: pack/unpack uncontrovercial enhancements
> RFC 247: pack/unpack C-like enhancements
>
> RFC 248: enhanced groups in pack/unpack
>
> RFC 249: Use pack/unpack for marshalling
>
> RFC 250: hooks in pack/unpack
>
> The following enhancement covers almost all the
How about a Base64 to match with uuencode?
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> =head1 ABSTRACT
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
Adam Turoff writes:
> >From here on out, Frozen RFCs shall remain Frozen. Should the maintainer
> wish to clarify them after they have been frozen, the version number
> will increment by some fractional value (.01?), and a
> "Clarified: DD MMM " header will be added to the metadata.
>
> Obj
On Mon, Sep 18, 2000 at 12:18:19PM -0600, Nathan Torkington wrote:
> I'm against fractional version numbers on the grounds that it's
> another piece of knowledge that must be held before someone can
> understand the system (think of 5.004_54 and how hideous that system
> was). Integers imply all
Adam Turoff writes:
> I want to assert to the reader that there have been no substantive
> changes since v3 if an RFC was frozen at v3, but is currently v5.
>
> A "Frozen Since: v3" attribute should make this apparent.
Sure. And rather than rediddling all the other RFCs, only introduce
this whe
Ken Fox wrote:
>
> "David L. Nicol" wrote:
> > Hey, none of those are better than "It would be nice"
> >
> > They're all reasons why it would be nice
>
> I'm a little hazy on what you think is a "better" reason if all
> of mine were variants of "it would be nice."
> ...
> i.e. It would be nice.
On Mon, Sep 18, 2000 at 10:18:41AM -0600, Nathan Torkington wrote:
> Piers Cawley writes:
> > The idea here is to allow people to get ideas on the lists in a rough
> > form where they can get some initial comments (which may blow the
> > 'real' RFC out of the water...). There should be some very s
On Mon, Sep 18, 2000 at 02:18:50AM -0400, Michael G Schwern wrote:
> On Mon, Sep 18, 2000 at 01:35:42AM -0400, Adam Turoff wrote:
> > Background: RFCs should be in development until frozen or retired.
> >
> > Problem: Frozen RFCs are being updated.
>
> Solution #4: Slip the RFC status back to '
On Mon, Sep 18, 2000 at 10:12:33PM +1100, Jeremy Howard wrote:
> Some background would help--how is Larry being fed these RFCs?
By pointing his browser to http://dev.perl.org/rfc/. Just like the
rest of us.
I seriously doubt he's using Grail or tkWeb as his browser though. :-)
Z.
On Mon, Sep 18, 2000 at 02:04:51AM -0400, Bennett Todd wrote:
> 2000-09-18-01:35:42 Adam Turoff:
> > Background: RFCs should be in development until frozen or retired.
>
> An interesting puzzle. As the author of RFC 70, I've felt like I
> should make some updates, but they've been utterly trivial
I will never, ever, ever possibly begin to process all this mail.
It's completely impossible. I have three days before I leave the
country for three weeks, and nothing is done. Therefore, my answer
to you will be short and underdone. One can type on p6 lists *all*
day and get no nearer to closu
On 13 Sep 2000 07:07:42 -, Perl6 RFC Librarian wrote:
>Make length(@array) work
One more thought:
>Many newbies think of the number of
>elements in an array as its "length"
Doesn't this reflect C's idea of "a string is an array of characters"?
Which isn't the idea behind strings in Perl.
On Mon, Sep 18, 2000 at 01:02:31PM -0700, Glenn Linderman wrote:
> OK, thanks for the info. I'm not an internals guy, but I guess I
> should have written the benchmark. It just _seemed_ they should be
> slower, because there is more work to do the hashing. The actual
> lookup, I agree, should b
Michael G Schwern wrote:
> Similar mistaken logic leads to "globals are faster than lexicals".
Maybe so, but I'd think lexicals would be faster, because more of the lookup is
done at compile time rather than runtime... so I'm not sure what is similar
about the mistaken logic... for arrays, more
Let's table this discussion, please. There are two different concerns
here:
1. IO::Handle et al *are* too damn big and slow.
2. Bareword filehandles *are* a pain to deal with.
Perl 5.6 already has a lot of this solved by allowing lexically-scoped
variables to hold filehandles. We should
At 9:08 -0700 2000.09.18, Nathan Wiger wrote:
>Chris Nandor wrote:
>>
>> >just assume "All Perl core functions should return objects", and hence
>> >the reason I wrote RFC 73. ;-)
>>
>> And it would make me stop using Perl faster than your object method could
>> be resolved.
>
>Is your concern one
> 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 quote)?
> For example,
>
>$matrix1->[2..5; 2..4] * $matrix2->[1,3,
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
NC> $htdoc = open uri "http://www.yahoo.com" or die;
NC> with uri in the standard library
NC> and also make it easy to stack the module that does uri at the top of 'file'
NC> so that the default is to call the uri stuff.
Is it just me, but
Eryq wrote:
> And all that I am saying is that this syntactic complication,
> this special case where "the filehandle name *is* the object",
> should be gotten rid of. Unlike some other special Perl syntactic
> constructs (e.g., regular expressions, "here-is" documents),
> the current filehandl
The following is intended as a draft of the final draft of RFC 120
"Implicit counter in for statements, possibly $#".
It includes summarised alternatives based on discussions in this list. It
is not intended that this post should revive these discussions. It is a
chance for the contributing pa
On Mon, 18 Sep 2000 23:11:28 +0100, John McNamara wrote:
> foreach $item (@array) {
> print $item, " is at index ", $#, "\n";
> }
Maybe I'm a little late... But I just thought how neat it would be if
this would also extend to map() and grep().
Remember, officially the processing
> =head2 Choice of notation
>
> The placeholder notation has been chosen to be consistent with the
> eisting Perl scalar notation (but using a ^ prefix rather than a $):
>
> RoleScalar Placeholder
> var analog
>
> named
> > =head2 Choice of notation
> >
> > The placeholder notation has been chosen to be consistent with the
> > eisting Perl scalar notation (but using a ^ prefix rather than a $):
> >
> > RoleScalar Placeholder
> > var
Nathan Wiger wrote:
>
> Either we need to change $1 to $0, or change ^0 to ^1. Considering $0
> has been around a little while longer than HOFN, I strongly suggest we
> change ^0 to ^1 to be consistent.
>
> I realize this RFC has been frozen, but this is an important issue. And
> remember, Mike
> Let's jump in. This RFC proposes a C builtin with the following
> syntax:
>
Err... this syntax isn't what I expected at all! I thought the first
argument would define the shape of the result, like NumPy or PDL...
> When one array is passed in, it is split up. Here, the C<$x> and C<$y>
> determi
> Sorry Nate--I know we thought we were on the same wavelength here, but it
> looks like we weren't at all! Would you like me to redraft this for you, or
> create a new RFC?
It's all yours. My brain is toast, and I'm totally RFC'ed out. The only
thing I care about is that the lists wind up on the
Damian Conway wrote:
>
> That's it! I'm gonna take that whole section out and burn it!
;-)
> $1 is the *only* place in Perl where an index starts at 1. *It's* the one
> that's inconsistent. Fix *it*.
I'd love to. But we're stuck, unless we make a $CMD which holds what $0
currently holds, whic
On Sun, Sep 17, 2000 at 11:25:49PM -0700, Nathan Wiger wrote:
> > I also don't see that the optimization of one half of the accessor vs
> > the other is worth the trouble.
>
> Well, it depends on how much faster the autoaccessor is. If it is much
> faster, and you need to access a whole bunch of
On Mon, Sep 18, 2000 at 05:39:48PM +1100, Damian Conway wrote:
> I suggest that the requirement be:
>
> print "There are Dogs::->num_dogs() species of dogs.";
>
> I.e. use the unambiguous form of class method call.
Uhhh... I never even knew that worked. With the exception of OO book
a
>I doubt anyone's arguing that they're not function calls. What I find
>"surprising" is that Perl doesn't DWIM here. It doesn't encourage data
>encapsulation or try to make it easy:
> my $weather = new Schwern::Example;
> print "Today's weather will be $weather->{temp} degrees and sunny.";
>
> > I suggest that the requirement be:
> >
> > print "There are Dogs::->num_dogs() species of dogs.";
> >
> > I.e. use the unambiguous form of class method call.
>
> Uhhh... I never even knew that worked. With the exception of OO book
> authors, everyone's goin
On Mon, Sep 18, 2000 at 05:49:28AM -, Perl6 RFC Librarian wrote:
> Here's where the problem lies. Even though we now have a subclass
> of Frog, the Forest class is still referencing the original Frog
> class and not Frog::Japanese.
The DBI has this very problem! DBI->connect() returns DBI::
> > my $weather = new Schwern::Example;
> > print "Today's weather will be $weather->{temp} degrees and sunny.";
> > print "And tomorrow we'll be expecting ", $weather->forecast;
>
> You are wicked and wrong to have broken inside and peeked at the
> implementation and then
On Mon, Sep 18, 2000 at 01:12:10AM -0600, Tom Christiansen wrote:
> You are wicked and wrong to have broken inside and peeked at the
> implementation and then relied upon it.
That's a new one for perldiag. Would that be (S) or (X)?
> > print "Thanks, $cgi->param('name') for your order!";
> >
1 - 100 of 180 matches
Mail list logo
