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

2000-09-02 Thread Nathan Wiger
Tom Christiansen wrote: > > >Well, it only does this if it's not something like 'split', then! > > Yes, it does "do it" with split. split is defined to do what it > does, how it does it. *This* is the kind of senseless harping that > annoys me, Nathan. H. I'm apparently not making myself

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

2000-09-02 Thread Nathan Wiger
Damian Conway wrote: > > * invoke some other hierarchy of automagic methods > (REFIT? RESHAPE? MORPH? TRANSMOGRIFY?), or If we do go this way, then we should make sure any names follow suit: BLESS REBLESS CREATE RECREATE INVOKE REINVOKE SHAPE

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

2000-09-02 Thread Michael G Schwern
On Sat, Sep 02, 2000 at 11:05:23AM +1100, Damian Conway wrote: >> This bothers me. It leaves no way to override the behavior of a >> parent's SETUP and DESTROY, you can only overlay. You mentioned that >> this is normal for most other OO languages, so I presume there's a way >> t

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: Change "($one, $two)=" behavior for optimization? (was Re: RFC 175 (v1) Add C keyword to force list context (like C))

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

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 f

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

2000-09-02 Thread Tom Hughes
In message <[EMAIL PROTECTED]> Nathan Wiger <[EMAIL PROTECTED]> 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

other parts of the guts playing with raw access (was Re: A tentative list of vtable functions)

2000-09-02 Thread Bradley M. Kuhn
Bryan C. Warnock wrote: > I use direct, raw access in prototyping when dipping back into C for > "heavy" data manipulations - bit stream analysis, signals processing, etc. > Since I'm usually doing a lot of buffer manipulations, I don't want all > the scalar overhead that comes into play. > > >M

Re: RFC 72 (v3) Variable-length lookbehind: the regexp engine should also go backward.

2000-09-02 Thread Bart Lateur
On 1 Sep 2000 20:50:20 -, Perl6 RFC Librarian wrote: >Imagine a very long input string containing data such as this: > >... GCAAGAATTGAACTGTAG ... > >If you want to match text that matches /GA+C/, but not when it >follows /G+A+T+/, you cannot at present do so easily. Under this >proposal

Re: RFC 72 (v3) Variable-length lookbehind: the regexp engine should also go backward.

2000-09-02 Thread Peter Heslin
On Sat, Sep 02, 2000 at 01:52:09PM +0200, Bart Lateur wrote: > On 1 Sep 2000 20:50:20 -, Perl6 RFC Librarian wrote: > > >Imagine a very long input string containing data such as this: > > > >... GCAAGAATTGAACTGTAG ... > > > >If you want to match text that matches /GA+C/, but not when it >

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

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

[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 tb.";&{$F

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 b

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 au

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

2000-09-02 Thread Nathan Wiger
John Siracusa wrote: > > 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 automatic chain of events > for SETUP/DESTROY (without requiring the programmer to create and document > his own bug-free implementation) and i

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 othe

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

2000-09-02 Thread Randal L. Schwartz
> "Perl6" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: Perl6> This RFC proposes that the second argument to C 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 Cons

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 C. 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.

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 185 (v1) Thread Programming Model

2000-09-02 Thread Steven W McDougall
> > I dropped the I<$thread>->C call from this interface, and didn't > > say what happens if a thread Cs. There are several possibilities > I think that the try stack should unwind all the way through the new Thread > call -- that is, that the catches for the block that the thread was started > i

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-02 Thread Nick Ing-Simmons
Damian Conway <[EMAIL PROTECTED]> writes: > > > But I agree that anything beyond that is simply horrible. You'll only > > > drive more people *away* from OO, because it generates so horribly > > > inefficient code. If you want a constructor called, than FGS *call* a > > > constructor. Mayb

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

2000-09-02 Thread Nathan Wiger
> > So, you don't define a SETUP. BUT, the author of a module you're > > inheriting from defined a SETUP, not to your knowledge? > > No worse that the current situation in which you have no clue what the > guy you're inheriting from expects. Better to have SETUPs called > below you than to not e

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

2000-09-02 Thread Mike Lambert
> I can most certainly think of cases where a base class's DESTROY does > something a derived class doesn't like. Consider your example, > File::Lock. File::Lock::DESTROY calls flock($fh, LOCK_UN). I derive > File::Lock::Mac from File::Lock. Uh oh, Macs don't implement flock! > Under your prop

Profiling

2000-09-02 Thread Nick Ing-Simmons
This is from a perl5.7.0 (well the current perforce depot) compiled with -pg and then run on a smallish example of my heavy OO day job app. The app reads 7300 lines of "verilog" and parses it with (tweaked) Parse-Yapp into tree of perl objects, messes with the parse tree and then calls a method

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 Christi

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

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 C with a generic C function C takes a list of strings that describe aspects of the

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

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 C with a generic C function >C takes a list of strings that describe aspects of the >

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

2000-09-02 Thread Damian Conway
> Ever consider then having > > ($a, $b, $c) = ; > or > @a[4,1,5] = ; > > only read three lines? I think this is a superb idea, and look forward to someone's RFC'ing it. Damian

Re: a syntax derived from constant-time hash-based n-dim matrices in perl 5

2000-09-02 Thread c . soeller
"David L. Nicol" wrote: > > Nathan Wiger wrote: > > > Well, this is not bad, only it's not without its problems. Say you > > wanted to get your indices implicitly: > > > > @a[getindices()]; > > @a[$r->get_x, $r->get_y]; > > @a["@{\(getindices())}"]; > @a[join $",$r->ge

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

2000-09-02 Thread Matt Youell
> goes? Your logic suggests that I'd never want to meddle in the base's > implementation. What happens when the base classes' author finally fixes the problem you wrote around (and incidentally changes touchy implementation details in the base)? What happens someday when you can't see the implem

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 t

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

2000-09-02 Thread Damian Conway
> BLESS is still my top choice by far, because while it doesn't do any > blessing, it's obvious what it's attached to. I think it's misleading. > Remember, PRINT and PRINTF don't have to do any printing, nor do > POP, PUSH, etc, have to do any popping or pushing. But SETUP *neve

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 C RFC out today. > One thing nobody's brought up is this: What if you decide you want the >

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

2000-09-02 Thread David E. Wheeler
On 1 Sep 2000, Perl6 RFC Librarian wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Objects : Private keys and methods Here, here & amen, Damian! This one gets my instant vote! David

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-02 Thread David E. Wheeler
On Sat, 2 Sep 2000, Nick Ing-Simmons wrote: > Damian Conway <[EMAIL PROTECTED]> writes: > > > > But I agree that anything beyond that is simply horrible. You'll only > > > > drive more people *away* from OO, because it generates so horribly > > > > inefficient code. If you want a constructo

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:13:17AM -0700, Matt Youell wrote: > What happens when the base classes' author finally fixes the problem > you wrote around (and incidentally changes touchy implementation > details in the base)? What happens someday when you can't see the > implementation of the base c

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

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

2000-09-02 Thread Michael G Schwern
On Sun, Sep 03, 2000 at 11:35:53AM +1100, Damian Conway wrote: >> If you can figure a way out of the dilema I proposed above, I suppose >> this makes sense. > > Easy. Don't let File::Lock::Mac inherit from File::Lock. Have it *delegate* > to File::Lock instead. See my forthcoming C RFC.

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
> Yes, welcome to the dirty, icky real world. Life sucks, people will > write bad code, you will have to inherit from it. Sometimes you have > to break a little encapsulation to make an omlet. I'd rather it was > not so, but its better to accept it and deal than deny. > > Of

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

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

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

2000-09-02 Thread Tom Christiansen
>I don't want that to change. I simply want that return (I'm not sure >how to phrase this) be able to return only a scalar or an aggregate. die unless wantarray; >It should be immune from having a scalar context pushed through from >the caller and change the commas from a list seperator into the

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

2000-09-02 Thread Damian Conway
> Modulo some superpositional silliness, Hey! I resemble that remark! Damian