Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()

2000-09-10 Thread Damian Conway
I *still* think it should be "unmerge"! ;-) Damian

Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()

2000-09-10 Thread Chaim Frenkel
"DC" == Damian Conway [EMAIL PROTECTED] writes: DC I *still* think it should be "unmerge"! ;-) Hrmpf. It should be reshape. (Which would be its own inverse and saves a keyword.) chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED]

Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()

2000-09-10 Thread Jeremy Howard
Removed perl6-announce x-post Chaim Frenkel wrote: "DC" == Damian Conway [EMAIL PROTECTED] writes: DC I *still* think it should be "unmerge"! ;-) Hrmpf. It should be reshape. (Which would be its own inverse and saves a keyword.) reshape() has already been proposed (RFC 148):

Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()

2000-09-10 Thread Christian Soeller
Jeremy Howard wrote: However I like the Numeric Python reshape() semantics better: http://starship.python.net/~da/numtut/array.html Is that in any significant way different from PDL's reshape? http://pdl.sourceforge.net/PDLdocs/Core.html#reshape PS: How does one pronounce 'hrmpf'?

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Michael G Schwern
So I thought of a serious problem with part of this RFC. The bit about using indirect object syntax... Instead, this RFC proposes that Ctie's operation become much more fundamental, simply translating functions via the existing indirect object syntax: tie Transaction

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Nathan Wiger
Michael Fowler wrote: =head3 Merge CTIESCALAR, CTIEHASH, and CTIEARRAY into CTIE I'm not so sure about this. I'm not either anymore. This will probably be removed from the next version. Instead, this RFC proposes that Ctie's operation become much more fundamental, simply translating

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Michael G Schwern
On Sun, Sep 10, 2000 at 04:00:30PM -0700, Nathan Wiger wrote: Normally, the Foo::lock() subroutine in the current package will be called. However, if %trans is a tied hash to a class which defines a lock() method (let's call it Lock::Ness) the meaning of the program radically and

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Michael G Schwern
On Mon, Sep 11, 2000 at 01:31:39PM +1100, Damian Conway wrote: Or, better still, pass a reference to the actual variable being tied. Good idea. Also notice that I suggested the TIE be called as a method, so that it can be inherited if necessary (maybe you had that idea already???) The tie

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Nathan Wiger
Michael G Schwern wrote: sub lock { print "Hello!" } $trans = new Lock::Ness; lock $trans; # $trans-lock That's not right. You're correct. Sorry for not double-checking my examples. the same reasons I've already pointed out. You don't want adding a method to a class to

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Damian Conway
Also notice that I suggested the TIE be called as a method, so that it can be inherited if necessary (maybe you had that idea already???) The tie *can* currently be inherited. Yes, I was aware. It's just that you wrote: tie Some::Class $foo, @args;

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Michael G Schwern
On Sun, Sep 10, 2000 at 09:22:39PM -0700, Nathan Wiger wrote: Regardless of my huge error above, this doesn't change the fact that this is exactly what tie() does currently in Perl 5. That is: tie @a, 'Matrix'; push @a, $stuff; Now changes the meaning of push() in the current

Re: Beefier prototypes (was Re: Multiple for loop variables)

2000-09-10 Thread Damian Conway
my_while { pred() } { # don't gimme no Tcl flac. ... } # no semicolon needed here! DC Just added to the RFC :-) How would the parser handle this? Some '}' would need ';' some don't. The trailing C parameter specification tells the parser that there the last

RE: RFC 199 (v2) Another question...

2000-09-10 Thread Damian Conway
Would it be possible to expand the function prototypes so that a function could be defined to take a loop block instead of a code block? I'm not sure what you mean here. Damian

Re: RFC 114 (v2) Perl resource configuration

2000-09-10 Thread Chaim Frenkel
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: but that is the user's to set. PERL_PRELOAD TC is there for the user to unset. allows the admin to globally set (in the system shell rc file) the rc files that perl will load. TC And what sorts of things might the admin care to globally

Re: $a in @b

2000-09-10 Thread Chaim Frenkel
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: grep { $_ == 1 } 1..1_000_000 grep doesn't short-circuit. TC I never did figure out why "last" {w,sh,c}ouldn't be made to do TC that very thing. Hey, I suggested that a while ago, but Randal shot it down. Something about the block not

Re: $a in @b

2000-09-10 Thread Chaim Frenkel
"DC" == Damian Conway [EMAIL PROTECTED] writes: DC I would propose that the Cgrep operation should short-circuit if the DC block throws an exception, with the value of the expection determining DC whether the final invocation of the block should accept the element it DC was filtering: Why not

Re: $a in @b

2000-09-10 Thread Randal L. Schwartz
"Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes: "TC" == Tom Christiansen [EMAIL PROTECTED] writes: grep { $_ == 1 } 1..1_000_000 grep doesn't short-circuit. TC I never did figure out why "last" {w,sh,c}ouldn't be made to do TC that very thing. Chaim Hey, I suggested that a while ago,

Re: RFC 103 (v1) Fix print $r-func and $pkg::$var precedence

2000-09-10 Thread Glenn Linderman
Nathan Wiger wrote: Bart Lateur wrote: Why interpolate "$obj-method" and not "Class-method"? This is a decent point worth considering. I think another way to look at it which is more accurrate is that - is special in many cases already: /$foo-{blah}/ # - special