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 Saf
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
>
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
> exercise) and they haven't, so I'm happy. :)
Something like Function::Over
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 inte
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 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
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
f
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 b
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 in-
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
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.
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
"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
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
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
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 modifie
16 matches
Mail list logo
