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

[Jo Rhett]

On Jan 29, 2007, at 5:26 AM, Ivan Kohler wrote:
> 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?

#3 and checkFormat are related in that I would attempt to do both at  
the same time. This change would make both of those easier to  
accomplish.

> 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?

I'm not certain that we need Exceptions in the classic sense.   
Exceptions are a form of goto() and I can't really see them as  
relevant to this environment.  We make a call -- that call either  
returns success, or various types of failure.  Normal "return" with  
some strings holding the error message would work perfectly fine in  
this environment, AFAIK.  (ie. what you already have today, just  
extended for module setup errors too)

The backwards compatibility is easy.  Right now you have to wrap the  
module invocation in an eval.  So you do that.  On return, you check  
$@ as well as the return code.  If either shows failure, you either  
use $@ or the module's error string as the answer.

Once you know that all of your modules are safe from needing eval {}  
you can stop using eval, and just check the return code.

In essence, I think that little/no changes are required immediately  
and that removal of the eval and a check of the modules error status  
are the only changes required.

Would it help if I supplied patches to the LinkPoint and AuthorizeNet  
modules demonstrating what I mean?

> 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
> _______________________________________________
> bop-devel mailing list
> bop-devel at 420.am
> http://420.am/cgi-bin/mailman/listinfo/bop-devel

-- 
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness