I really don't like that it uses closures to be honest, because closures are a totally unrelated concept that would be needed to understand why declaring the request suddenly needs to be done with that extra sub layer (maybe a (&) prototype might help). Or that would mean using the syntax "because that's how it works", ie, enforced cargo-culting. And even if you understand closures, it's not really their normal use (potentially shared, static-like variables) but hacking around their implementation and side effects (access the variables outside their scopes, delay the interpolation), so that's magic where the implementation leaks into the calling context, the wrong kind of magic IMHO.
If tying the variables allows you to remove the closures I think that's fine, but otherwise if using your tools requires tied variables and closures, that would be too many advanced concept to make using DBI "simpler".
In reply to Re: RFC: Placeholder creation for SQL statements
by Eily
in thread RFC: Placeholder creation for SQL statements
by LanX
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |