An alternate design is to derive from Foo::Parse.Interesting approach, but I was specifically interested in callbacks in this case. And -FWIW- in my real world program it's not to be a single sub, but a dispatch table...
Note that $self in the callback doesn't make much sense - it's a Foo::Parse object, and the callback is not a method of Foo::Parse. Better to name it $obj or $fp.Very good point, in fact I've been lucubrating for a while as for what a good name for what I eventually called $self may have been. Incidentally in my real world program it will be a more descriptive name, like $log, so no problem here. As far as generic use is concerned, $obj is fine IMHO.
Very good point too! I like closures, I just hadn't thought of this possibility...This makes it into a closure, meaning that $fp remains visible. Even if $fp were itself no longer in scope, this closure can still see it. This is even more normal to me.my $fp; $fp = Foo::Parse->new('FooParser', sub { local $_ = shift; s/^\w+:// or $fp->warn("something wrong!"); split /,/; } );
In reply to Re^2: Seeking advice for OO-related strategy
by blazar
in thread Seeking advice for OO-related strategy
by blazar
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |