On Tue, Feb 20, 2001 at 02:19:18PM +, Simon Cozens wrote:
Sort of. What I really wanted to do was to be able to say
sub foo { ... }
builtinify(foo);
package bar;
foo(); # Refers to main::foo
package baz;
foo(); # Refers to main::foo
(this is so that the forthcoming Safety::First
On Tue, Feb 20, 2001 at 01:49:45AM -0500, [EMAIL PROTECTED] wrote:
On Tue, Feb 20, 2001 at 02:14:52AM +, Simon Cozens wrote:
Yes. And the modules on CPAN that already do this are interesting too.
Oh, bother. Oh well, I've got builtinify (which was actually the point of the
Incidentally, I just implemented pre- and post- handlers on subroutines
in pure Perl 5, without any changes to the language. Interesting, huh?
sub foo { print "Bar\n"; }
append_to_sub {print "After!\n"} foo; # Perl 5.6.x (\) syntax
append_to_sub {print "After!\n"}, \foo; # Perl 5.6 syntax
On Mon, Feb 19, 2001 at 06:46:11PM +, Simon Cozens wrote:
This actually came as a side-track to something else I was doing which was to
make some subroutines appear like builtins; (available from all packages)
I'll put Sub::Versive on CPAN when I've done *that*.
It's up. Enjoy.
--
Use
Simon Cozens wrote:
Incidentally, I just implemented pre- and post- handlers on subroutines
in pure Perl 5, without any changes to the language. Interesting, huh?
Yes. And the modules on CPAN that already do this are interesting too.
--
John Porter
On Mon, Feb 19, 2001 at 09:00:11PM -0500, John Porter wrote:
Simon Cozens wrote:
Incidentally, I just implemented pre- and post- handlers on subroutines
in pure Perl 5, without any changes to the language. Interesting, huh?
Yes. And the modules on CPAN that already do this are
Tony Olekshy wrote:
Glenn Linderman wrote:
Tony Olekshy wrote:
By rule 2 above, it would seem that if $p-foo raises an Error:IO
exception, that the except block hasn't yet been seen, and
therefore the block should propagate unwinding.
Ah, yup. ++$bugs{$self}
OK, good. I was
Glenn Linderman wrote:
you'll note that RFC 119 does, in fact, place catch statements inside
the scope of the block to which they apply,
Yup! I wish I could take credit for this, historically, but an
examination of the archives shows that Glenn holds priority.
So in RFC 119, we have
John Porter wrote:
So in RFC 119, we have in-scope catch statements, dangling except
clauses, and dangling always clauses.
I'll go on the record as saying that I am totally opposed to
dangling "clauses" of any kind.
Now that's just the sort of Gibralter-like position that begs to be
(1)
"David L. Nicol" wrote:
Tony Olekshy wrote:
If we take this approach then when you just want to casually say
my $f = open $file; always { close $f };
you can. I like that. In addition, [...]
How about "later" instead of "always"
Because: "later" is a time in the future, but
Glenn Linderman wrote:
Tony Olekshy wrote:
If we take this approach then we know exactly what the following
code will do.
{ my $p = P-new();
$p-foo and always { $p-bar };
except Error::IO { $p-baz };
}
We also know when the block propagates
On Wed, Feb 14, 2001 at 07:40:26PM -0700, Tony Olekshy wrote:
The problem may be that a dynamic always statement means both
"no matter what happens" and "not until later". The static
finally clause just means "no matter what happened" (the effect
is immediate).
I'm fond of post, myself.
Tony Olekshy wrote:
2. Support always and except blocks. These constructs may be used
without requiring a try before the block. They are dynamic
operations which only come into play when they are encountered
in the block, in run-time order.
...
If we take this approach then
Tony Olekshy wrote:
If we take this approach then when you just want to casually say
my $f = open $file; always { close $f };
you can. I like that. In addition, when you want to carefully ...
How about "later" instead of "always"
Because: "later" is a time in the future, but we
I've been thinking about the effect of the minimalist changes I
made to the RFC 88 reference implementation, and I don't see any
good reason not to support both the static and the dynamic forms
of end-of-block-scope actions. Consider the following proposal.
1. Support a try statement (a
15 matches
Mail list logo
