Re: The distinction between do BLOCK while COND and EXPR while COND should go

2000-09-02 Thread Chaim Frenkel
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: It might be worthwhile enough to kill sub fn { return (7,8,9,10) } $x = fn(); # $x == 10 TC But this happens many places. What about @foo[4,1,9,-2]? TC It's just a listish thing. One should learn. I don't want that to change. I

Re: RFC 178 (v1) Lightweight Threads

2000-09-02 Thread Chaim Frenkel
"SWM" == Steven W McDougall [EMAIL PROTECTED] writes: Not unless it is so declared my $a :shared. SWM Sure it is. SWM Here are some more examples. SWM Example 1: Passing a reference to a block-scoped lexical into a thread. Depends on how locking/threading is designed. There is a fundemental

Re: RFC 39 Perl should have a print operator

2000-09-02 Thread Ken Rich
Perl supplies an operator for line input - angle brackets. This is no analogous operator for output. I propose "inverse angle brackets": How about quotes? A quoted lhs expression could mean print. A quoted lhs expression preceded by a file handle could mean print to filehandle. Tom

Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

2000-09-02 Thread Matt Youell
Damian Conway wrote: * invoke some other hierarchy of automagic methods (REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or REINCARNATE

Re: RFC 187 (v1) Objects : Mandatory and enhanced second argument to Cbless

2000-09-02 Thread Randal L. Schwartz
"Perl6" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: Perl6 This RFC proposes that the second argument to Cbless be made Perl6 mandatory, and that its semantics be enhanced slightly to cover a Perl6 common, ugly, and frequently buggy usage. Yes! -- Randal L. Schwartz - Stonehenge

Re: RFC 190 (v1) Objects : NEXT pseudoclass for method redispatch

2000-09-02 Thread Randal L. Schwartz
"Perl6" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: Perl6 This RFC proposes a new pseudoclass named CNEXT. Perl6 This pseudoclass would provide a way of correctly redispatching a method Perl6 or an autoloaded method. Yes! -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

2000-09-02 Thread John Tobey
On Sat, Sep 02, 2000 at 12:16:48AM -0400, John Tobey wrote: I agree with Michael that SETUP should be BLESS. You argue that it Oops, I mean Nate. Sorry, Michael! -John

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

2000-09-02 Thread Nathan Wiger
Michael G Schwern wrote: Derived classes will never have to override a base's implementation, and all member variables should be private, and everyone will always use an accessor, and the UN will bring about world peace, and as long as I'm wishing for a perfect world, I'd like a pony. ;)

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

2000-09-02 Thread John Siracusa
On 9/2/00 11:34 AM, Nathan Wiger wrote: It doesn't seem that it's that hard to add a single line to your SETUP or BLESS or whatever method that calls SUPER::SETUP. I'm pretty sure one of the big points about the system described is that it ensures both that there's always a predictable and

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

2000-09-02 Thread Tom Christiansen
The whole notion of blessing is non-obvious enough already. It's the benedictory (con)not(at)ion of blessing, not the bless()ing itself that so confuses people, I think. It bless() were instead named something like mark stamp label brand retype denote notate

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers anddestructors

2000-09-02 Thread John Siracusa
On 9/2/00 12:12 PM, Nathan Wiger wrote: I think this RFC could work for this, but as I noted in a private email to Damian I'd rather see a whole new keyword made, maybe "setup"? sub new { setup {}, @_ } sub SETUP { ... } Sure, but does setup() bless? That's the question... :) In other

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-02 Thread Damian Conway
private $self-{data} = $derdata; should be $derdatum here? Yes. Thanks. Damian

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

2000-09-02 Thread Damian Conway
I'm still not totally convinced that its so horrid to make the File::LockAndKey DESTROY call $self-SUPER::DESTROY manually... Believe me, it is in a large, deep, and/or MI hierarchy! but it does break encapsulation. Exactly. If you can figure a way out of the dilema I

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers anddestructors

2000-09-02 Thread Damian Conway
The "multiple inheritance paths" one is good. I like that part a lot. But the rest makes me really nervous if there's no way to override or change it. There is. I'll try and get the Cuse delegation RFC out today. One thing nobody's brought up is this: What if you decide you

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

2000-09-02 Thread Michael G Schwern
On Sat, Sep 02, 2000 at 03:18:06PM -0400, Mike Lambert wrote: In certain cases, like the one in which you proposed, you'd want to explicitly bypass the parent DESTROY. sub DESTROY { my $self = shift; $self-UNIVERSAL::DESTROY(@_); } would skip the automatic chaining because the

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

2000-09-02 Thread Damian Conway
Also, its not entirely clear why method chaining is desired only for constructor and destructors. What about every other method? Constructors and destructors are special. They're not about *doing* something; they're about *being* (or not being) something. A "doing" method *may* wish to

Re: RFC 114 (v2) Perl resource configuration

2000-09-02 Thread Ariel Scolnicov
Uri Guttman [EMAIL PROTECTED] writes: "TC" == Tom Christiansen [EMAIL PROTECTED] writes: many systems allow for a global/local startup file for various reasons. i see a potential use of this in perl but i don't see the specific use yet. build it they will use it. TC But Perl

Re: RFC 114 (v2) Perl resource configuration

2000-09-02 Thread Michael G Schwern
On Fri, Sep 01, 2000 at 11:40:13PM -0400, Uri Guttman wrote: "TC" == Tom Christiansen [EMAIL PROTECTED] writes: TC But Perl is not an interactive shell! Can you imagine if a C TC compiler allowed arbitrary amounts of text to be pre-included and what about the proposals for an

Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar))

2000-09-02 Thread Jeremy Howard
Tom Hughes wrote: For example, in Perl you have for a long time been able to do this: ($one, $two) = grep /$pat/, @data; However, what currently happens is grep goes to completion, then discards possibly huge amounts of data just to return the first two matches. For example, if

Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar)

2000-09-02 Thread Randal L. Schwartz
"Tom" == Tom Christiansen [EMAIL PROTECTED] writes: Tom Wherever you think you need one of these, try to think again. Either Tom it's already in list context, in which case it's silly to put in Tom the list thing, or else there's always a better way to accomplish Tom whatever you're trying to

Re: RFC 114 (v2) Perl resource configuration

2000-09-02 Thread Andy Dougherty
On Fri, 1 Sep 2000, Tom Christiansen wrote: it can be used for system specific @INC paths without recompiling perl That's what PERL5LIB is for. PERL5LIB is available for the individual user to use, set, unset, change, etc., at will. As sysadmin, you can't set it in /etc/profile and be

[OT} Universal shell configuration

2000-09-02 Thread Jerrad Pierce
It's called meta shell ftp://www.guug.de/pub/members/truemper/metash -- #!/usr/bin/perl -nl BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;}); $_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";{$F[0]};sub t{*t=sub{}; return if rand().5;$_="Vg'f abg lbhe ghea lrg, abj

Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar))

2000-09-02 Thread Damian Conway
Here is my suggestion: What if other functions were able to backtrace context and determine how many arguments to return just like split can? I have an RFC on that: RFC 21: Replace Cwantarray with a generic Cwant function Cwant takes a list of strings that describe

Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar))

2000-09-02 Thread Tom Christiansen
Here is my suggestion: What if other functions were able to backtrace context and determine how many arguments to return just like split can? I have an RFC on that: RFC 21: Replace Cwantarray with a generic Cwant function Cwant takes a list of strings that describe