[Dbix-class] Re: [OT][ANNOUNCE] SQL Generation with SQL::DB

[Emanuele Zeppieri]

A. Pagaltzis wrote:

> * Emanuele Zeppieri <ema_zep at libero.it> [2007-09-07 11:15]:
>> Mark Lawrence wrote:
>>> If that is so, then you are asking how the following is
>>> evaluated?
>>>
>>>    ($track->length > 248) & ! ($cd->year < 1997)
>> No, I'm asking how it could be *built* by code without string
>> concatenations/interpolations.
> 
> Uh. They’re Perl expressions. Don’t you know how to write
> conditionally executed Perl expressions? What are you doing on
> this list? :-)
> 
>     use List::Util qw( reduce );
> 
>     my @cond;
> 
>     # in real code the following stuff would be more systematic;
>     # this is just to demonstrate the principle
> 
>     if ( $min_track_length ) {
>         push @cond, $track->length > $min_track_length;
>     }
> 
>     if ( $max_year ) {
>         push @cond, $cd->year < $max_year;
>     }
> 
>     my @where = @cond
>         ? ( where => reduce { $a & $b } @cond )
>         : ();
> 

ROTFL! :-)

Not only a bunch of reduce()'s are mainteinibility-wise even worse than 
string concatenations

(did you understand that also subexpressions like:
"$track->length > $min_track_length"
and
"$track->length > $min_track_length"
must be built *dinamically*, from arbitrarly user data, not statically 
in the code as you did in your example? :-)

but, if you perform a sequence of reduce()'s, you should even find the 
correct order to honor the operators precedences.
Basically, you're rewriting an SQl parser, thus fully bypassing the 
SQL::DB expression parser (and reimplementing it in your code, 
congratulations! :-)

You did consider that, right?

So, who should reconsider his presence on this list? (as well as in the 
programming world in general :-)

Regards,
Emanuele.