[bop-devel] let's talk about eval, baby :-)

Ivan Kohler ivan at 420.am
Mon Jan 29 05:26:46 PST 2007


I'm not opposed to any of the below (though I don't see how #3 and 
"checkFormat" are related to any of this), but what alternate exception 
handling method do you propose instead?

And.. how do we get from the current state of things to the new-style 
exceptions, preserving backwards compatibility for end-users and module 
authors?

-- 
_ivan


On Thu, Jan 25, 2007 at 09:04:50AM -0800, Jo Rhett wrote:
> So let's talk about eval and the use of eval {}.  One of the things 
> which bothers me is the lack of debugging in most of the modules.  I'm 
> totally willing to do this work, but having to eval the module 
> invocation makes this kind of work much more difficult.
> 
> I'm wondering if we can get agreement on a few principles:
> 
> 1. The application should never have to eval() a B:OP method.
>    (it can if it wants, but it should not be required)
> 
> 2. If it is necessary for the gateway module to eval() something that it 
> invokes (like lpperl.pm's submit function), it should be handled inside 
> the gateway module and invisible to the application.
> 
> #1 and #2 allow for introspection and good debug.
> 
> 3. All transactor objects should provide a standardized debug() method 
> (or methods if we determine that more than one is necessary) that 
> returns debug from the current transaction.  It should perhaps accept an 
> optional level as input, and return debug of that level or higher? 
> (optional)
> 
> The last one might require the most buyin, and perhaps not part of the 
> immediate deliverable, but I'd like a method which does all of the data 
> testing but none of the actions.
> 
> $transtion->checkFormat( \%content );
> 
> This could allow the provider to test the data input and confirm that 
> the gateway module likes it before actually invoking the method. 
> Depending on the tie-in to the shopping cart, they might use this method 
> in between the data input and the confirm order screen ....
> 
> -- 
> Jo Rhett
> Network/Software Engineer
> Net Consonance


More information about the bop-devel mailing list