A. Pagaltzis wrote:
Hi Emanuele,
* Emanuele Zeppieri <[EMAIL PROTECTED]> [2007-09-07 13:25]:
A. Pagaltzis wrote:
* Emanuele Zeppieri <[EMAIL PROTECTED]> [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
News to me.
I can only see one `reduce` in that code, btw.
Yes, indeed it remains a mistery why you thought that the "&" operator
required a reduce while the ">" and the "<" operators didn't :-)
But anyway, `reduce` shouldn’t be necessary here, the SQL::DB API
could do that work internally. But I’ve already said that.
It was only you that have the brilliant idea to resort to an
(unnecessary) reduce, do you remember that pal? It happened only few
hours ago :-)
(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? :-)
How is my code not building them dynamically? If
$min_track_length has no value, then that condition is not added
to the code. Please explain to me how your SQLA data structure
manipulation code is somehow more dynamical than that.
The above mentioned relational expressions are dynamic *only* as long as
you live in a little contrived universe where the $track->length field
can only be compared through the ">" operator and the $cd->year field
only through "<".
Actually, go ahead: post some magic dynamical SQLA query builder
code that I can’t translate to SQL::DB. Let’s watch me fail.
Examples in points 2 and 4 in my response to Mark, please.
Anyway don't cheat: I've never said that you can't do them with SQL::DB,
I just said that It'll require more code.
but, if you perform a sequence of reduce()'s, you should even
find the correct order to honor the operators precedences.
`reduce` folds left to right. What things are more to the left
and which are more to the right in the array will depend on the
order in which I put them in the array.
Funnily enough, that means I have to pay attention to exactly the
same things as I would have had to if I were building SQLA query
data structures.
Basically, you're rewriting an SQl parser, thus fully bypassing
the SQL::DB expression parser (and reimplementing it in your
code, congratulations! :-)
Point me to which part of my code does any parsing.
Indeed you didn't do any parsing, which means that you cannot handle
more dynamic cases (as the ones showed in my examples in points 3 and 4).
Point me to which part of my code is conceptually different from
what an SQLA data structure builder snippet does.
You did consider that, right?
Why should I? It’s wrong.
Don't mark as wrong something you are not able to understand.
So, who should reconsider his presence on this list? (as well
as in the programming world in general :-)
Oh crap, you’re right. I should pack my bags and leave. :-)
Just for a vacation.
It could even relax you ;-)
Regards.
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
