[Boston.pm] Fwd: Calling a function that will return to where the grandparent called the parent
*grumble*reply-to*grumble*
-- Forwarded message --
From: Guillermo Roditi [EMAIL PROTECTED]
Date: May 31, 2007 2:28 PM
Subject: Re: [Boston.pm] Calling a function that will return to where the
grandparent called the parent
To: Alex Brelsfoard [EMAIL PROTECTED]
Take a look at, and the source of
http://search.cpan.org/~drolsky/Devel-StackTrace-1.15/lib/Devel/StackTrace.pmhttp://search.cpan.org/%7Edrolsky/Devel-StackTrace-1.15/lib/Devel/StackTrace.pm
On 5/31/07, Alex Brelsfoard [EMAIL PROTECTED] wrote:
Hi All,
I'm looking for a quick and easy way to have this situation happen:
sub Plort {
...
...
Foo();
...
}
sub Foo {
...
...
Error();
...
}
I want it to happen that when Error() is called, when Error() finishes
doing
what it does it returns you to it's parent's parent (Plort() in this
case).
I don't want to have to specify anything.
I want it to always return you to where Error()'s grandparent called it's
parent.
Any ideas of how to do this?
Thanks.
--Alex
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Calling a function that will return to where the grandparent called the parent
Use die() or croak() paired with eval() for exception-passing.
use Carp qw(carp croak);
sub Plort {
...
...
eval { Foo() };
if ($@) {
carp Onoz, an error!!;
do_something_with_error($@);
}
...
}
sub Foo {
...
...
croak(Error());
...
}
Alernately, have the Error sub throw the exception instead.
On 5/31/07, Alex Brelsfoard [EMAIL PROTECTED] wrote:
Hi All,
I'm looking for a quick and easy way to have this situation happen:
sub Plort {
...
...
Foo();
...
}
sub Foo {
...
...
Error();
...
}
I want it to happen that when Error() is called, when Error() finishes doing
what it does it returns you to it's parent's parent (Plort() in this case).
I don't want to have to specify anything.
I want it to always return you to where Error()'s grandparent called it's
parent.
Any ideas of how to do this?
Thanks.
--Alex
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
--
Jason McIntosh
Email: [EMAIL PROTECTED]
Jabber: [EMAIL PROTECTED]
AIM:zendonut
Cell: 617-792-3829
President and Founder
Volity Games
http://volity.net
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Educational (and fun) evening event, May 31
On 5/17/07, Andy Oram [EMAIL PROTECTED] wrote: O'Reilly is sponsoring an evening of talks and tech play in Cambridge. I really think it will be quite informative, but alcohol will be available and the crowd should be a fascinating group to mingle with. FWIW, I'll be there tonight, giving a five-minute version of the Volity presentation I gave to Boston.pm last month. It will have less Perl and more funny pictures. There's a full schedule up on the Ignite Boston blog now: http://www.oreillynet.com/ignite/blog/ -- Jason McIntosh Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] AIM:zendonut Cell: 617-792-3829 President and Founder Volity Games http://volity.net ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Calling a function that will return to where the grandparent called the parent
Hi Alex,
What you're asking is possible, especially since you only asked for quick and
easy
and said nothing about elegant ;)
The situation you describe is known as a 'condition' in Lisp, which allows
you to define the catch and handle exceptional conditions in your program,
including *restarting* the offending piece of code (presumably after
changing program state to prevent looping). Most other languages use a
catch-throw construct, which is spelled die-eval in Perl.
Basically, you need to place an eval in Plort and die in Error with a
specific error string (or other unique value) that Plort can use to
distinguish your particular situation from some other error. As you can see,
both routines have to cooperate to make this work: one to throw the error and
the other to catch it.
Here's an example.
#!/usr/bin/env perl
use strict;
$\ = \n;
#note the all important newline, which prevents perl from helpfully appending
#more text to our error string.
our $ERROR_CONDITION = Error-Condition\n;
sub Plort {
print in Plort, calling Foo();
eval {
Foo();
};
if ($@){
if ($@ eq $ERROR_CONDITION) {
print caught error condition. All is well;
}
else {
#some other error
die;
}
}
print in Plort, back from Foo();
}
sub Foo {
print in Foo, calling Error();
Error();
print in Foo, back from Error, but you'll never see this line;
}
sub Error {
print in Error;
die $ERROR_CONDITION;
}
__END__
Plort();
On Thu, May 31, 2007 at 02:11:44PM -0400, Alex Brelsfoard wrote:
Hi All,
I'm looking for a quick and easy way to have this situation happen:
sub Plort {
...
...
Foo();
...
}
sub Foo {
...
...
Error();
...
}
I want it to happen that when Error() is called, when Error() finishes doing
what it does it returns you to it's parent's parent (Plort() in this case).
I don't want to have to specify anything.
I want it to always return you to where Error()'s grandparent called it's
parent.
Any ideas of how to do this?
Thanks.
--Alex
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Calling a function that will return to where the grandparent called the parent
On Thursday 31 May 2007, Alex Brelsfoard wrote:
Hi All,
I'm looking for a quick and easy way to have this situation happen:
sub Plort {
...
...
Foo();
...
}
sub Foo {
...
...
Error();
...
}
I want it to happen that when Error() is called, when Error() finishes
doing what it does it returns you to it's parent's parent (Plort() in this
case). I don't want to have to specify anything.
I want it to always return you to where Error()'s grandparent called it's
parent.
Any ideas of how to do this?
Perhaps you want to look at exceptions:
http://www.shlomifish.org/lecture/Perl/Newbies/lecture4/exceptions/
(Note: this is something I wrote.)
It's not exactly what you want, but you may be able to re-engineer your
program using Object Oriented exceptions. Also look at Exception::Class,
which has less dark magic than Error.pm, but has less syntactic sugar. (which
in Error.pm's case is rather error-prone).
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
If it's not in my E-mail it doesn't happen. And if my E-mail is saying
one thing, and everything else says something else - E-mail will conquer.
-- An Israeli Linuxer
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Calling a function that will return to where the grandparent called the parent
On Thu, May 31, 2007 at 03:22:32PM -0400, Gyepi SAM wrote: Here's an example. Small editing error with my example: the '__END__' should be after the call to Plort(). -Gyepi + Plort(); + + __END__ instead of - __END__ - - Plort(); ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] overriding instance methods, dynamic package namespaces
/me curses forgotten thread I actively contribute to the codebase of both Moose and MOP, so if you have questions etc I'm usually good about either saying Yeah, I think it'd be fun to try to implement $IMPOSSIBLE_TASK or say No go, and this is why and here's a good workaround On 5/18/07, Tom Metro [EMAIL PROTECTED] wrote: Guillermo Roditi wrote: Please take a look at Class::MOP and Class::MOP::Class. Sounds like a little -meta foo would makeyour life easier... Introspection is good and good for you! http://search.cpan.org/~stevan/Class-MOP-0.37/ Indeed. It even includes one of the things I was looking for - a facility to create (simulated) anonymous classes: http://search.cpan.org/~stevan/Class-MOP-0.37/lib/Class/MOP/Class.pm create_anon_class (superclasses = [EMAIL PROTECTED], methods = ?%methods, attributes = ?%attributes) This will create an anonymous class, it works much like create but it does not need a $package_name. Instead it will create a suitably unique package name for you to stash things into. There's an intro/review of Class::MOP here: http://www.oreillynet.com/onlamp/blog/2006/06/cpan_module_review_classmop.html but it just scratches the surface and doesn't really get into the stuff in Class::MOP::Class that's of relevance to my application. Thanks for the pointer. -Tom -- Tom Metro Venture Logic, Newton, MA, USA Enterprise solutions through open source. Professional Profile: http://tmetro.venturelogic.com/ ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Calling a function that will return to where the grandparent called the parent
From: Gyepi SAM [EMAIL PROTECTED]
Date: Thu, 31 May 2007 15:22:32 -0400
Hi Alex,
What you're asking is possible, especially since you only asked for
quick and easy and said nothing about elegant ;)
The situation you describe is known as a 'condition' in Lisp, which allows
you to define the catch and handle exceptional conditions in your program,
including *restarting* the offending piece of code (presumably after
changing program state to prevent looping) . . .
Well, the notion of restarting also includes such things as skip the
operation, suppress the warning, etc. The try the same thing again
restarts are mostly intended for use by interactive debuggers, where
looping is not a problem.
The thing I find most impressive about the Common Lisp condition
system is that it allows the signalling (detection) of an error, the
provision of restart/retry code, and the decision of which restart, if
any, to take (handling) to be implemented by three different people
writing at different times and communicating only through software
documentation. See [1] for a general overview of Lisp conditions.
However, since Alex seems to have control over all of the code
involved, there is a simpler approach. The following version of your
Plort example uses a callback [2] that closes over the done: label
instead of using eval/die:
#! /usr/bin/perl -w
use strict;
use warnings;
use vars qw($callback);
sub Plort {
print in Plort, calling Foo()\n;
local $callback = sub {
print In callback.\n;
goto DONE;
};
Foo();
print in Plort, returned from Foo() [not]\n;
DONE:
print in Plort, done with Foo()\n;
}
sub Foo {
print in Foo, calling Error()\n;
Error();
print in Foo, back from Error, but you'll never see this line;
}
sub Error {
print in Error, invoking callback.\n;
$callback-();
}
Plort();
Note that this script works in Perl 5.8.1, but not in 5.6, where the
lexical sub is not allowed to goto a label that is in the containing
lexical scope. I don't know exactly when this feature was added/bug was
fixed.
Running this produces the following output:
[EMAIL PROTECTED] perl-condition.pl
in Plort, calling Foo()
in Foo, calling Error()
in Error, invoking callback.
In callback.
in Plort, done with Foo()
[EMAIL PROTECTED]
Two advantages of this technique spring to mind:
1. It is transparent to eval/die, so it doesn't muck up other error
processing, an unfortunate weakness of resignalling [3]. In particular,
introducing an eval to the internals of Foo can never intercept the
nonlocal exit performed by the callback.
2. The notion of how many levels to exit (the parent/grandparent
thing) doesn't have to be hardwired. The Error sub can be called at
arbitrary points within the implementation of Foo, at different levels,
and will still do the right thing in each case.
HTH,
-- Bob Rogers
http://rgrjr.dyndns.org/
[1] Kent M. Pitman, Condition Handling in the Lisp Language Family,
http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html
[2] Need I say what else I could have called it? ;-}
[3] Perl 6 will do this better.
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
