[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cgiapp] Re: ANNOUNCE: ::Plugin::ValidateRM 2.00_01 with new dfv() method


Mark Stosberg wrote:
> Thanks for the feedback Michael. Comments below. 
> 
> On 2005-07-12, Michael Peters <suppressed> wrote:
> 
>>Mark Stosberg wrote:
>>
>>>Hello,
>>>
>>>I've just uploaded a new developer release of ValidateRM to CPAN, which
>>>you can also get here:
>>>
>>> http://mark.stosberg.com/dfv/CGI-Application-Plugin-ValidateRM-2.00_01.tar.gz
>>>
>>>I added a dfv() method as an alternate way to access the results object
>>>that's generated. I think this will be of primary interest to other
>>>plugin authors rather than users.
>>
>>Nice! Since there is now a better way to access the results how about
>>making the return from check_rm cleaner too? Would you consider allowing
>>
>>  my $error_page = $self->check_rm(...);
>>
>>It would just have to check wantarray() to DTRT in scalar context. This
>>would simplify things a lot IMHO. And it would still be backwards
>>compatible.
> 
> 
> 
> I'm not included to do this. Here's why. 
> 
>   # What's going on here? These statements don't seem related
>   # ... unless I go read some documentation. 
>   my $error_page = $self->check_rm(...);
>   $self->dfv->valid('email');
> 
>   # Oh, now I see the connection. 
>   my ($results,$error_page) = $self->check_rm(...);
>   $results->valid('email');

Well, I don't expect most people would do the first option. It would
probably look more like:

  my $error_page = $self->check_rm(...);
  if( $error_page ) {
    return $error_page;
  } else {
    my $email = $self->dfv->valid('email');
  }

Which seems very readable to me.

> Passing data around in through the object is one step away from the
> evilness of global variables.

That's a little overstated imo. Object data is a great place to put
information that should persist for the duration of that object (for the
entire request cycle in the case of C::A).

Why is the above an abuse of dfv()? What wouldn't be a bad use?

> Explicit parameter passing is easier to debug and less error prone in my
> opinion.

I agree. I'm not talking about trying to avoid passing the results
object to other subs that might need it. I'm talking about having a
method return multiple items when there's a perfectly good object to get
them from later should you want them.

-- 
Michael Peters
Developer
Plus Three, LP


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed


Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.