At 04:32 AM 8/23/00 +, Perl6 RFC Librarian wrote:
>One Should Not Get Away With Ignoring System Call Errors
> Mailing List: [EMAIL PROTECTED]
I think this should be perl6-language-errors
>In the following 'system calls' mean anything not in the core language
>calling an external service, b
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Enhanced Pack/Unpack
=head1 VERSION
Maintainer: Edwin Wiles <[EMAIL PROTECTED]>
Date: 22 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 142
=head1 ABSTRACT
Pack and Unpack a
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
This Is The Last Major Revision
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 22 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 141
=head1 ABSTRACT
Future perl ve
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
One Should Not Get Away With Ignoring System Call Errors
=head1 VERSION
Maintainer: Jarkko Hietaniemi <[EMAIL PROTECTED]>
Date: 22 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 14
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow Calling Any Function With A Syntax Like s///
=head1 VERSION
Maintainer: John Porter <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 139
=head1 ABSTR
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Eliminate =~ operator.
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 22 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 138
=head1 ABSTRACT
Replace EXPR =~ m/.../ w
On 23 Aug 2000, Perl6 RFC Librarian wrote:
> Since versioning is a meta-implementation issue, all that is required
> is that fearless leader has to agree this is a good idea.
Very funny. I suppose you don't mind if he changes his mind someday?
I'm starting to think that you have too much time
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Implementation of Threads in Perl
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 01 Aug 2000
Last Modified: 22 Aug 2000
Version: 3
Mailing List: [EMAIL PROTECTED]
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> does that apply to a set of keys? or a particular hash ref used as the
>> object?
DC> It applies to the nominated keys of the nominated hash.
DC> private $hash{secret}; # Just this key is private
DC>
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
object neutral error handling via exceptions
=head1 VERSION
Maintainer: Glenn Linderman <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Last Modified: 22 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> "David L. Nicol" wrote:
>> > In perl 6 the keys and values functions should no longer use the
>> > same iterator as the each function - each use of keys and values
>> > should use it's own private iterator instead.
DLN> we
Tony Olekshy wrote:
> Glenn Linderman wrote:
> >
> > Perl 5 doesn't have exceptions, which is precisely how it avoids this
> > problem.
>
> Perl 5 has exceptions. my $x = 0; my $y = 1 / $x; It avoids nothing,
> which is we are always mixing return-based and exception-based failure
> signalling.
On Wed., Aug 16, 2000, Nate Wiger wrote:
> is good. Right now, people are hopping in 500 emails behind, replying to
> something in the middle of the stream, and only later reading the
> "please move this to -errors" post.
Actually, I'm 1283 emails behind, to be exact.
And that's just countin
At 11:58 PM 8/22/00 +0200, Markus Peter wrote:
>On Tue, 22 Aug 2000, Glenn Linderman wrote:
> > > throw an exception as a means of reporting "file is not there anyway" -
> > > which I absolutely do not care about...
> >
> > Well, if they die on you, there's not much you can do about it. But if
>
At 12:28 PM 8/22/00 -0700, I wrote:
The issue is not whether it is possible but whether it is desirable. Chaim
thought that the P5 continue block scope issue was 'fixed' by Gurusamy at
some point and this is almost certainly correct. Observe:
>% perl5.003 -Mstrict -we 'my $x = 2; while($x--)
Gads, people, I can barely go to the bathroom without getting behind on
this discussion, let alone head out for a few hours to pick up a new laptop
:-) I'll try to catch up.
At 07:25 PM 8/22/00 -0600, Tony Olekshy wrote:
>Throw can't take no arguments because its a constructor, not a function.
David L. Nicol writes:
> Do either of those expressions make sense in terms of
> references to something? If not, then syntactically we
> are in the clear. They don't, because currently it makes
> no sense to butt a reference up to the LHS of anything.
>
> It isn't any less clear than, for inst
On Wed, Aug 23, 2000 at 12:17:18AM +, David L. Nicol wrote:
> Nathan Torkington wrote:
> > The precedent of "if you're doing a hash
> > lookup, use {} around the key" is fairly well-ingrained in Perl.
>
> I don't care how "ingrained" the concept of wrapping the
> field names in curlies is, I
"Brust, Corwin" wrote:
>
> > From: Tony Olekshy [mailto:[EMAIL PROTECTED]]
> >
> > That's well and good, but the source code syntax says it's a block,
> > not a sub. Am I supposed to spend the rest of my life asking myself,
> > "Wait, is this one of Corwin's special blocks?" ;-)
> >
> > I thin
I have modified RFC 88 so that the following
=head1 DESCRIPTION
throw Exception::IO "a message", tag => "ABC.1234", ... ;
now reads like this:
=head1 DESCRIPTION
The most common forms of structured exception handling are straight-
forward. Here they are:
try { ... } catch { ...
-Original Message-
From: Jeremy Howard [mailto:[EMAIL PROTECTED]]
[...]
Programmers shouldn't have to know how a
computer implements things behind the scenes--which is really what requiring
explicit looping forces.
Great point, this should be in the RFC.
-Corwin
Dan Sugalski wrote:
>
> Any variable that has a 'per-thread' component should be self-contained.
>
> Dan
We don't know how many instances of iteration happening in the
program there will be, or how many there can be. If each instance
of hash iteration
-Original Message-
From: Tony Olekshy [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 22, 2000 6:27 PM
To: [EMAIL PROTECTED]
Subject: Re: Exception stack: let's use the @@ list.
That's well and good, but the source code syntax says it's a block,
not a sub. Am I supposed to spend the r
Nathan Torkington wrote:
> Except that you often don't know the keys in advance, and so now
> your code turns into:
>
> with %one\$keytwo {
> push @\$keythree\$keyfour, 5, 6;
> }
>
> which is decided sub-clear.
Do either of those expressions make sense in terms of
references to some
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> >But, for simple scripts, Perl's inconsistency I just what I like.
>
> Never thought I'd hear you say that :-)
Who, me? I'm a hopeless pragmatist. That's why I want try for big
programs. Pragmatically, that works better there. That's why I do
Markus Peter wrote:
>
> ... then I run into trouble
> if the method author does not even know wether its procedural or OO.
What I wrote is dependent on an environmnet where the C keyword
is used to write methods that are distinct from subroutines, and
also, a C with the same name could be writt
On Tue, 22 Aug 2000, David L. Nicol wrote:
>
> > we could put it in a variable associated with the instance of the
> > keyword. An associative array of threads to current-values.
>
> or in the "global per-thread data area" keyed to some immutable-during-the-run
> value.
Or, since shared varia
> we could put it in a variable associated with the instance of the
> keyword. An associative array of threads to current-values.
or in the "global per-thread data area" keyed to some immutable-during-the-run
value.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"Brust, Corwin" wrote:
>
> Tony Olekshy wrote:
> >
> > Consider this case:
> >
> > catch $@->{severity} eq "Fatal" => { ... }
> >
> > Are you proposing to make @_ the exception stack in the catch
> > expressions too, as is:
>
> nope, just B C.
>
> catch grep $@->isa($_), qw( list_o_clas
Glenn Linderman wrote:
>
> Perl 5 doesn't have exceptions, which is precisely how it avoids this
> problem.
Perl 5 has exceptions. my $x = 0; my $y = 1 / $x; It avoids nothing,
which is we are always mixing return-based and exception-based failure
signalling. This is not going to go away, and
In message <[EMAIL PROTECTED]>
"David L. Nicol" <[EMAIL PROTECTED]> wrote:
> "David L. Nicol" wrote:
>
> > > In perl 6 the keys and values functions should no longer use the
> > > same iterator as the each function - each use of keys and values
> > > should use it's own private iterator
# # -Original Message-
# # From: Tony Olekshy [mailto:[EMAIL PROTECTED]]
# # Sent: Tuesday, August 22, 2000 4:01 PM
# # To: [EMAIL PROTECTED]
# # Subject: Re: Exception stack: let's use the @@ list.
# # Peter Scott wrote:
# # >
# # > Brust, Corwin wrote:
# # > >
# # > > I've come to
Markus Peter wrote:
>
> I could not find this in the online RFC 88 - what version are we
> talking about?
Sorry, it's available as below. This draft hasn't been sent to the
RFC index yet because I'm waiting on Peter's comments.
Formatted: http://www.avrasoft.com/perl/rfc/rfc88v2d5.htm
POD as
Glenn Linderman wrote:
>
> I think we agree that both/either type of APIs can be provided by a
> module author with suitable wrappers. Or a module can provide one, and
> another module written to wrap it and provide the other. I think we
> agree that an exception, if thrown, should be caught an
Oops, accidentally sent message. Here's the final version.
Chaim Frenkel wrote:
>
> Actually, why not simply unwind the call stack to the routine that
> has the pragma active.
>
> sub foo {use exception; &baz()}
>
> sub baz { throw "a fit" }
>
> sub bar {
>
"David L. Nicol" wrote:
>
> >
> > In perl 6 the keys and values functions should no longer use the
> > same iterator as the each function - each use of keys and values
> > should use it's own private iterator instead.
we could put it in a variable associated with the instance of the
keyword. An
>
> In perl 6 the keys and values functions should no longer use the
> same iterator as the each function - each use of keys and values
> should use it's own private iterator instead.
And a separate one for each thread, too -- can't forget that --
>
> Consider the following syntax:
>
> my var; # declaring a scalar
> my array[]; # declaring an array
> my hash{};# declaring a hash
For the remainder of the enclosing block, the barewords var,
array and hash are to be interpreted as references to a scalar, an
array, and a ha
Peter Scott wrote:
>
> I thought the discussion was around how
>
> throw object;
>
> could be a run-time error if object ! isa Exception (which is
> what I think should happen) if
>
> throw LIST;
>
> had to have the same semantics as die LIST.
We can't do constuctor and LIS
Tom Christiansen wrote:
>
> Have all here please looked at
>
> use Fatal qw(:void open close);
>
> yet?
>
> thanks,
Thanks for the gentle reminder Tom. Yes we have. When I use
the generic C in my comments, I'm referring to just
that sort of functionality.
Everyone here seems to agree th
David L. Nicol writes:
> okay but we still have the hiding issue, in case we want it to
What's the hiding issue? I must have missed that.
> $one{two} is $one\two
> $$one{two}{three} is $one\two\three
> $$$one{two}{three}{four} is $one\two\three\four
Your le
>
>> Is there any mileage in extending the syntax to allow the contents
>> of an array or hash to be checked. In general I find quite often
>> that I am checking to make sure that an array has at least N
>> elements (ignoring issues with sparseness) and that a hash has a
>> s
Chaim Frenkel wrote:
>
> Actually, why not simply unwind the call stack to the routine that
> has the pragma active.
>
> sub foo {use exception; &baz()}
>
> sub baz { throw "a fit" }
>
> sub bar {
> no exception;
> &foo();
> }
Ye
On Tue, 22 Aug 2000, David L. Nicol wrote:
> And you dont have to make sure the $s on the left of the names match
> the {}s on the right, just use one $ and string the names together with
> backslashes. This is not easier?
>
>
> $one{two} is $one\two
> $$one{two}{three}
With a tied scalar, does perl5 access its routines
twice when it does a += ?
I think the lvalueable subroutine should get called twice
in the example, first the left-hand and then the right-hand
Nathan Wiger wrote:
>
> Damian Conway wrote:
> >
> > The lvalue accessor *shouldn't* be d
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> From the reactions on this thread so far I am wondering whether the
PS> message I sent out about it when it had a different name got
PS> through. Relevant excerpt:
PS> Well, you could certainly have a pragma that makes throw set $! to
Nathan Torkington wrote:
> # making this part up
> struct Person => [ qw(Name Age Height Weight) ];
> # but once you have a named structure, you can say ...
> my Person %nat;
> with (%nat) {
> $Name = "Nathan"; # rewritten to $nat{Name} at compile-time
> ...
> }
>
> It's ki
On Tue, 22 Aug 2000, Glenn Linderman wrote:
> > throw an exception as a means of reporting "file is not there anyway" -
> > which I absolutely do not care about...
>
> Well, if they die on you, there's not much you can do about it. But if they throw
> an exception, you will only die if you don't
This sounds like another job for the macro language.
Anyone have any idea what the macro language should look
like, aside from that the variables in it which will get
replaced might wear hats?
defining -language-macro might be premature because identifying
what suggestions and shortcuts make
>> I don't see how it gets more complicated if you really want to
>> ignore errors. If you really want to ignore errors, you have to do
>> this in Perl 5 right now anyway, but you say eval { ... }; instead.
> open ( FOO, "<$file" );
>ignores errors.
>eval ( open ( FOO, "<$file" ));
>i
Tom Christiansen wrote:
> Have all here please looked at
>
> use Fatal qw(:void open close);
>
> yet?
>
> thanks,
>
> --tom
So that's a way of turning certain non-fatal errors into fatal errors for
the class of functions that happen to indicate non-fatal error via a false
return value. So w
Markus Peter wrote:
> On Tue, 22 Aug 2000, Glenn Linderman wrote:
> > I'm suddenly intuiting that maybe you want to continue execution after the sub
> > call that caused the throw. But if you continue, you won't have the return
> > values from the sub call. Where should the continuation take pl
Karl Glazebrook wrote:
>
> Just a test to see if this list is actually alive...
Seems to be. But no great activity yet. Where to start?
Christian
>Yes, but they are ever so slightly burdensome to use for very large blocks
>of text.
I've never understood that.
:/foo/,/bar/s/^/##XXX## /
does it for me. There are doubtless infinite variations on the same.
--tom
On Tue, 22 Aug 2000, Peter Scott wrote:
> At 04:06 PM 8/22/00 -0500, Brust, Corwin wrote:
> >So that was:
> >
> > Any exception raised in a try will be fatal unless caught?
>
> It already is (RFC 88).
Two more questions ;-)
1) I could not find this in the online RFC 88 - what version a
Tom Christiansen said:
> D.N.>I mean, really, why not?
>
> Because we already have comments.
Yes, but they are ever so slightly burdensome to use for very large blocks
of text. We really are talking Oranges and Tangerines here anyway (at least)
since one seems like it is meant to comment A Line w
At 04:06 PM 8/22/00 -0500, Brust, Corwin wrote:
>[snip]
>-Original Message-
>From: Markus Peter [mailto:[EMAIL PROTECTED]]
>Another way to achieve the same result would be to NOT get rid of the try
>part of try/catch and then try automatically implies use fatal for that
>block...
>
>So th
>It doesn't help that Camel II's glossary defines "array" as "A named list
>of values, each of which has a unique key to identify it. In a normal
>array, the key is numeric... In a hash...the key is a string." and seems to
>go to a lot of effort to deprecate "array" in favor of "list" (array
> Does this cover all the cases?
>
Does it allow not only die but everything w/in Carp.pm to be
implemented in terms of it?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Laziness with responsibility http://www.tipjar.com/kcpm
Peter Scott wrote:
>
> Brust, Corwin wrote:
> >
> > I've come to like @_ as our input list and think that
> > exception handling blocks would naturaly use this.
> >
> > Also it seems convienent, which seems perlish.
>
> I find myself indifferent on the subject of where the exception
> stack is sto
[to you only, as this thread is now distinctly off-topic for perl6-language]
Buddha Buck wrote:
>
> @array1 = (1, 1, 3, 5, 8, 13);
> %hash1 = ('foo', 34, 'bar', "not a number", 'baz', 4);
> @array2 = %hash1;
> %hash2 = @array1;
>
> This works, and may lead to confusion because:
This is exact
[snip]
-Original Message-
From: Markus Peter [mailto:[EMAIL PROTECTED]]
Another way to achieve the same result would be to NOT get rid of the try
part of try/catch and then try automatically implies use fatal for that
block...
--
Markus Peter
[EMAIL PROTECTED]
[/snip]
So that was:
At 12:43 AM 8/20/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > At 08:43 PM 8/19/00 -0600, Tony Olekshy wrote:
> > >Peter Scott wrote:
> > > >
> > > > Dave Rolsky wrote:
> > > > >
> > > > > Tony Olekshy wrote:
> > > > > >
> > > > > > die
> > > > > > If argument is anything else, ra
On Tue, 22 Aug 2000, Glenn Linderman wrote:
> I'm suddenly intuiting that maybe you want to continue execution after the sub
> call that caused the throw. But if you continue, you won't have the return
> values from the sub call. Where should the continuation take place for
> something like:
>
J . David Blackstone <[EMAIL PROTECTED]> writes:
>
> I may be making a bad assumption here, but since a package is
>usually (but not always) defined one per file, I'm assuming that in
>several of these places where you said "package" we should perhaps
>think "file."
It is common practice in perl
Tony Olekshy wrote:
> Glenn Linderman wrote:
> >
> > Some discussion has been made about ignoring errors from certain
> > parts of the code. This is the only item that gets more complex
> > with exception handling--they must be ignored explicitly
> >
> > { & ignore_my_errors ( @params ); catc
At 02:29 PM 8/22/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > But surely you have to be consistent. I understood Chaim's point to be
> > that he wanted no exceptions if he didn't ask for them. If the core
> > currently dies where it could return and set $!, then it is being
> > inco
At 04:11 PM 8/22/00 -0400, John Porter wrote:
>Casey R. Tweten wrote:
> >
> > There is no documentation that states:
> >
> > ``keys() just doesn't work on lists and/or arrays,
>
>Why should it bother saying that, when it already says keys() works on a
>HASH?
>
>Or is there some confusion that a H
Hildo Biersma <[EMAIL PROTECTED]> writes:
>
>> =head2 Inheritance
>>
>> As with the existing C/C pragmata, Perl 6
>> classes should support single, linear inheritance only. Multiple
>> inheritance is generally more trouble than it's worth.
>
>Yuck. MI is useful though sometimes abused, and even
At 11:52 AM 8/21/00 -0500, Brust, Corwin wrote:
>I've come
>to like @_ as our input list and think that exception handling blocks would
>naturaly use this.
>
>Also it seems convienent, which seems perlish.
>
>Hmmm...
>
> for (@plays) {
> $qb->pass;
> warn &&
Peter Scott wrote:
>
> But surely you have to be consistent. I understood Chaim's point to be
> that he wanted no exceptions if he didn't ask for them. If the core
> currently dies where it could return and set $!, then it is being
> inconsistent, since this is not an error that prevents perl f
On Tue, 22 Aug 2000, David L. Nicol wrote:
> Yes, that's pretty much it. More opportunity to be lazy, but only
> if you know how. This way the authors of methods never have to fiddle
> with checking ever again. And users who call methods like subroutines
> had better know what they are doing
Markus Peter wrote:
> --On 22.08.2000 10:48 Uhr -0700 Glenn Linderman wrote:
>
> What
> I was talking about is that I cannot imagine that the perl core itself
> magically transforms exceptions into return values as someone else
> requested.
We agree here.
> > "enabling/disabling fatality for ex
Today around 4:07pm, John Porter hammered out this masterpiece:
: Casey R. Tweten wrote:
: >
: > Removing intermediate data structures is easy in Perl, but not this case,
:
: C, etc. must have data structures to work on. There's no "getting rid"
: of them.
Perl can create them for me.
: "I w
At 02:00 PM 8/22/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> > I actually see nothing wrong in division returning undef for a
> > dividend of 0. It's just as easy to check as doing an eval.
>
>Please don't do this. I would have to check every divide in all
>my code, since no fatal is the
Peter Scott wrote:
>
> Given that even though we know the shared scope could be implemented,
> the implementors may prefer not to do it. I would therefore reword:
>
> > We would prefer that the blocks share a common lexical scope in the
> > way that C blocks used to; if this is deemed inappropr
Casey R. Tweten wrote:
>
> There is no documentation that states:
>
> ``keys() just doesn't work on lists and/or arrays,
Why should it bother saying that, when it already says keys() works on a HASH?
Or is there some confusion that a HASH might also be an ARRAY or a LIST?
--
John Porter
Markus Peter wrote:
>
> --On 22.08.2000 18:24 Uhr + David L. Nicol wrote:
>
> >
> > Regardless of what its called, in a method called as a subroutine,
> > the variable could refer to the last instance of this kind of object
> > used by this thread.
>
> Hmm Does that mean if I once all $
Casey R. Tweten wrote:
>
> Removing intermediate data structures is easy in Perl, but not this case,
C, etc. must have data structures to work on. There's no "getting rid"
of them.
"I want find /usr to search the directory tree, but, um, I don't want to
actually *have* a directory tree..."
And at this point we seem to have run out of steam for changing perl6
in this direction. Please take dialogue on the perl5 documentation to
the perl5-porters list.
Thanks,
Nat
>There is no documentation that states:
>``keys() just doesn't work on lists and/or arrays, you must use this syntax to
>force that to work:
> @array = keys %{{@array}};
>''
>Or something like that.
keys is documented to take a hash. Likewise, push an array.
This all seems completely obvious
Today around 1:51pm, Tom Christiansen hammered out this masterpiece:
: >As a user, I should be able to expect this:
:
: I've decided I don't believe you, because despite having taught a
: zillion people Perl,
Commendable. I value your expertise.
: I have never *once* seen the misexpectation
Peter Scott wrote:
>
> Now, I do not want that to detract completely from Chaim's point,
> which is well taken. I too would rather say
>
>my $fh = open $filename or die "Couldn't copy source: $!"
>
> than
>
>my $fh; try { $fh = open $filename }
>catch { die "Couldn't copy source:
Today around 1:41pm, Tom Christiansen hammered out this masterpiece:
: > my %hash = &func();
: > print "$_\n" foreach keys %hash;
:
: >To work just like this:
:
: > print "$_\n" foreach keys &func();
:
: >In my, 'pretending to just learn' mode, I don't understand. Perl will assign
: >the L
>As a user, I should be able to expect this:
I've decided I don't believe you, because despite having taught a
zillion people Perl, I have never *once* seen the misexpectation
and subsequent error that you're spending so much time complaining
about.
--tom
> > I think this is fraught with peril. I'd have expected:
> >
> > print (1, 2, 3, ...) or die;
> >
> > to print
> >
> > 12345678910111213141516171819202122232425262728etc
>
> No, if that's what you wanted, you'd get it with
>
>print( 1, 2, 3 ..
> my %hash = &func();
> print "$_\n" foreach keys %hash;
>To work just like this:
> print "$_\n" foreach keys &func();
>In my, 'pretending to just learn' mode, I don't understand. Perl will assign
>the LIST to the hash in example one, but in example two, it croaks.
A LIST is not a HASH. L
>I mean, really, why not?
Because we already have comments.
Because they don't nest.
Because there are already legal and semilegal sequences that look
like that. (No proof that such are used, since /foo/*3 doesn't
look very common, whereas /*foo/ is illegal, and $foo/*bar makes
rather little s
Today around 3:01pm, John Porter hammered out this masterpiece:
: Nathan Torkington wrote:
: > John Porter writes:
: > > I suppose that's true. But why would
: > > %( foo => 1, bar => 2 )
: > > be "working harder" than
: > > %{{ foo => 1, bar => 2 }}
: > > ??? It's few keystrokes and would
Glenn Linderman wrote:
>
> Some discussion has been made about ignoring errors from certain
> parts of the code. This is the only item that gets more complex
> with exception handling--they must be ignored explicitly
>
> { & ignore_my_errors ( @params ); catch {}};
I don't see how it gets m
At 11:59 PM 8/20/00 -0600, Tony Olekshy wrote:
>RFC 88v2d6 now leaves in shared lexical scope and says the following
>under ISSUES + Lexical Scope:
>
> If it is not possible to have try, catch, and finally blocks
> share lexical scope (due, perhaps, to the vagaries of stack
> unwinding
At 07:58 PM 8/22/00 +0200, Markus Peter wrote:
>What I was actually requesting was a small pragma which simply turns off
>all fatality, in the whole program, similar to what $SIG{__DIE__}
>currently is able to do,
Are you sure? $SIG{__DIE__} cannot prevent the program terminating once it
ret
John Porter writes:
> So? Perl's not like that. Perl is diagonal. And this is just
> another corner being cut.
Cut away enough corners, and you have a black hole. Or something :-)
My point is that before you reach to invent new syntax, see if there's
a way to do what you want with the existi
I mean, really, why not?
Nathan Torkington wrote:
> John Porter writes:
> > I suppose that's true. But why would
> > %( foo => 1, bar => 2 )
> > be "working harder" than
> > %{{ foo => 1, bar => 2 }}
> > ??? It's few keystrokes and would be a less tricky concept
> > to remember.
>
> It's a new syntax, not ortho
I assure you that the number of people who get compile-time caught
for writing keys or each $x[$i][$j] or pop or push $x[$i][$j] is
*very* large. This is by far the most prevalent error that happens
with data structures in apprentice and perhaps even journeymen perl
programmers. Having the compi
--On 22.08.2000 18:24 Uhr + David L. Nicol wrote:
>
> Regardless of what its called, in a method called as a subroutine,
> the variable could refer to the last instance of this kind of object
> used by this thread.
Hmm Does that mean if I once all $obj->method() and then afterwards
somew
>[Quoting David L. Nicol, on August 21 2000, 23:06, in "Re: RFC 132 (v1) sub"]
>> Looks like a case for automatic dereferencing!
>Which Perl has always stated it would _never_ do.
Kinda.
To be honest, Perl does do autoderef in at least two places.
1.
$fh = *FH;
$fh = \*FH
can be us
Regardless of what its called, in a method called as a subroutine,
the variable could refer to the last instance of this kind of object
used by this thread.
By the way, in my perl5 OO I always shift off the first one onto
my $this
John Porter writes:
> I suppose that's true. But why would
> %( foo => 1, bar => 2 )
> be "working harder" than
> %{{ foo => 1, bar => 2 }}
> ??? It's few keystrokes and would be a less tricky concept
> to remember.
It's a new syntax, not orthogonal to anything we already have. The
1 - 100 of 147 matches
Mail list logo
