> "DR" == Dave Rolsky <[EMAIL PROTECTED]> writes:
DR> On 22 Aug 2000, Chaim Frenkel wrote:
>> Could you tell me why you would want two finallys?
>>
>> Why not put them into one?
TO> my ($p, $q);
TO> try { $p = P->new; $q = Q->new; ... }
TO> finally { $p and $p->Done; }
TO> finally { $q and
Just a test to see if this list is actually alive...
Karl
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> =item *
>
> Changes to the semantics of C so that, after associating an
> object with a class, the class's C methods are automatically
> called on the object. An additional trailing C<@> parameter for
> C, to allow arguments to be passed to C met
Damian Conway <[EMAIL PROTECTED]> writes:
> > how would you travel up the @ISA tree and call INIT?
>
>Actually, you travel *down* the @ISA tree: the most ancestral INITs are
>called first.
Ha, you botanist you! - you have the leaves at the top, and root at
the bottom of your tree ;-)
--
Nick
--On 22.08.2000 12:24 Uhr -0400 Chaim Frenkel wrote:
> TO> return $FATAL_MODE ? ERROR_IO : throw Error::IO;
>
> Why make all module authors do that? Have core perl do that for you.
> Make a pragma that would treat throw as a return. No cost to the
> module author.
This probably won't work. W
[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.
Well, this could be the time of changes.
-- Johan
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
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
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 { ...
On Tue, Aug 22, 2000 at 06:31:14PM +0200, Markus Peter wrote:
> Well - after all it's just an implementation detail... My question is what's
> wrong to only supply the information on perl ports where systems do not
> have zoneinfo ? But I've to admit that I don't really care as long as we
> fina
At 6:43 +0200 2000.08.22, Markus Peter wrote:
>In my opinion there's no reason for localtime or gmtime to be in the
>core at all.
I can think of two outstanding reasons for them to be in the core: because
they've already been there, and there is no reason to take it out.
>I especially want to f
--On 22.08.2000 11:18 Uhr -0400 Chris Nandor wrote:
> If there's a good reason to remove localtime(), then fine. But please say
> something more than "web applications don't need it."
Well, I did not really talk about removing it - I know about the backwards
compatibility issues. I know my mail
At 17:44 +0200 2000.08.22, Markus Peter wrote:
>--On 22.08.2000 11:18 Uhr -0400 Chris Nandor wrote:
>
>> If there's a good reason to remove localtime(), then fine. But please say
>> something more than "web applications don't need it."
>
>Well, I did not really talk about removing it - I know abo
--On 22.08.2000 12:18 Uhr -0400 Chris Nandor wrote:
> Yes, well you did say, "In my opinion there's no reason for localtime or
> gmtime to be in the core at all." I guess that doesn't necessarily mean
> it should be removed in your opinion, but it sure seems like it.
As I said - my mail was eas
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]
Markus Peter wrote:
> --On 22.08.2000 12:24 Uhr -0400 Chaim Frenkel wrote:
>
> > TO> return $FATAL_MODE ? ERROR_IO : throw Error::IO;
> >
> > Why make all module authors do that? Have core perl do that for you.
> > Make a pragma that would treat throw as a return. No cost to the
> > module au
Chaim Frenkel wrote:
>
> What happens when Graham Barr decides to use throws in
> his Net::* modules. These are some of the most useful modules that
> I have been using. You have now forced me to switch to try/catch.
If Graham decides to use throws in Net::* he would be the one forcing
you to ch
Chaim Frenkel wrote:
>
> Tony Olekshy wrote:
> >
> > If you write this:
> >
> > try { my $p = P->new;
> > my $q = Q->new;
> > }
> > finally { $p and $p->Done;
> > $q and $q->Done;
> > }
> >
> > what happens if both constructors succeed, but $p->
--On 22.08.2000 10:48 Uhr -0700 Glenn Linderman wrote:
>> This probably won't work. What would you return exactly? Also, there's
>> plenty of chance that the return value could interfer with the regular
>> return values of that function... This will never be possible without
>> work done by the m
>[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
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
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
--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
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 $
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
> 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 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 ..
>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
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
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
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
>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
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
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..."
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
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 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
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
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
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
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
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
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 8/22/00 12:45 AM, Uri Guttman wrote:
> perl could be the uber OO language, capable of emulating ANY object
> style.
Is this more important than improving performance vs. Perl 5 OO?
Not IMO; I want speed. Hey, if I can have both, I'm all for it.
But if forced to choose...
-John
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}
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
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
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
>
>> 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
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
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
>
> 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 --
"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 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
> 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]
> "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>
>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
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
>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
I mean, really, why not?
Larry Wall wrote:
>
> Either that, or it's a funny unary operator that can take 0 or 1 argument.
>
> But I'd be happy with just ... as a statement. Dwimming the unary
> operator may not be worth it. Especially since it might be confused
> with the binary operator.
Could you make it "evapora
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
[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
>
> 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
>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
Damian Conway wrote:
>
> 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 .. ) # RFC 24
--
Jo
Piers Cawley wrote:
>
> You forgot:
> print (1, 11, 21, 1211, ...)
print( 'M', 'MI', 'MIU', ... )
ALso, Larry, how about making the various common emoticons meaningful?
please do come from 10; :-)
I.e. "belay that command".
--
John Porter
We're building the
Casey R. Tweten wrote:
>
> sub func {
> return qw/KeyOne Value1 KeyTwo Value2/;
> }
>
> print "$_\n" foreach keys &func();
Please. There are ways -- well, just one way -- to do this, even in perl5.
print "$_\n" foreach keys %{{ func() }};
--
John Porter
We're building t
In reply to your message from the not too distant future: next Monday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 10:15:48 EDT
From: Jerrad Pierce
>So, you
>So the internals stay almost the same, but before resorting to die,
>you attempt a cast, if it works you warn that's inefficient under strict,
>and of course in the docs. If I occasionally want to be inefficient, I should
>have the license to do so. But I really don't think it'll be that less
>ef
Numerical python uses "..." in the same sense for axis
lists in multi-dim arrays. (Improved syntax for multidim
arrays is one wishlist item from PDL for the perl core.
See RFC117)
NumPy allows you to say:
a[..., :];
where "..." means "however many", - so this is a slice along
the last dimen
Today around 10:11am, John Porter hammered out this masterpiece:
: Casey R. Tweten wrote:
: >
: > sub func {
: > return qw/KeyOne Value1 KeyTwo Value2/;
: > }
: >
: > print "$_\n" foreach keys &func();
:
: Please. There are ways -- well, just one way -- to do this, even in perl5.
:
:
Damian Conway wrote:
>
> Tom's opcode dumping functionality could, in principle, be added to
> Data::Dumper as it stands.
>
> My proposal was merely that C<&Data::Dumper::Dumper> body-snatch C.
But that's a crummy name for it, unix legacy not withstanding.
Is someone working on an RFC? IIRC,
Tom Christiansen wrote:
>
> Hmm, what about CHECK blocks?
CHECK blocks would be great! But of course, they work in memory,
which is not useful for persisting program state across executions,
or moving it across machines.
--
John Porter
We're building the house of the future together.
Larry Wall wrote:
>
> I'd entertain a proposal that ... be made a valid term that happens
> to do nothing, so that you can run your examples through perl -c for
> syntax checks. Or better, make it an official "stub" for rapid
> prototyping, with some way of getting a warning whenever you execute
Damian Conway wrote:
>
> Easy. I'll just add a C operator to Q::S. It would take no
> arguments and return a (lazy?) list of every possible Perl subroutine.
>
> PS: Can you tell whether I'm joking?
I think you're both joking AND not joking, at the same time.
--
John Porter
We're buil
On Tue, Aug 22, 2000 at 09:49:12AM -0400, John Porter wrote:
> Damian Conway wrote:
> >
> > Easy. I'll just add a C operator to Q::S. It would take no
> > arguments and return a (lazy?) list of every possible Perl subroutine.
> >
> > PS: Can you tell whether I'm joking?
>
> I think you're both
-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
Larry Wall wrote:
> John Porter writes:
> : Could you make it "evaporate" and compile time, just like the (proposed) qc()?
>
> Hard to make it evaporate at compile time and still give a warning at
> run time. :-)
Eh, eh... Curdle it into the appropriate warn() call!
--
John Porter
In reply to your message from the not too distant future: next Tuesday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 11:06:21 EDT
From: Jerrad Pierce
>It wil
Today around 11:06am, Jerrad Pierce hammered out this masterpiece:
: >It will show that you are doing what you *want* to do, not letting
: >automagic error-blind spoofery behind the curtains flummux up
: >your life unnecessarily.
:
: Umm no.. for what I *want* to do is take the keys of the hash
Larry Wall <[EMAIL PROTECTED]> writes:
> If you're into dwimmery, you could make all of these work, too:
>
> print (1, 2, 4, ...)
> print (1, 4, 9, 16, 25, ...)
> print (1, 1, 2, 3, 5, ...)
> print ('a', 'b', 'c', ...)
> print (3, 1, 4, 1, 5, 9, 6, 2, 5, ...)
You forgot:
John Porter writes:
: Could you make it "evaporate" and compile time, just like the (proposed) qc()?
Hard to make it evaporate at compile time and still give a warning at
run time. :-)
Larry
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
-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
>> 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
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
> "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
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
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
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
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 {
>
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
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:
>
> 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
# # -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
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
"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
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
"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
1 - 100 of 147 matches
Mail list logo
