On Sat, Aug 5, 2017 at 11:41 AM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
I disagree that my alternative requires more parameters.
I am just talking about the utility function itself, though. Your own
example shows that your function does require more parameters,
specifically two to my one.
(This isn't surprising, since your example is simply a restatement of
my example, but with different host language syntax.)
Let's say you're building a select statement and you want to have building
blocks for the WHERE clause.
I'd rather we not say that, because that's not what I'm trying to do.
Here's the thing: I completely understand what you're trying to do.
And there's certainly nothing wrong with what you're trying to do. But
someone else can come along and say "Joe, your utility function is all
well and good, but why so limited? Why not just add [a little more
functionality, for the "minimal" cost of a longer function signature,
and more code hidden within the function]?"
And you sort of went ahead and had that conversation yourself.
Before you know it, you have simply reinvented SQL itself, with custom
syntax. Or some subset of it. Kind of like the way Query/400 lets you
"avoid learning SQL" but then it turns out to be not that much easier
than SQL anyway, and you can only achieve a limited portion of SQL's
functionality with it.
I really just want what I want. It's a simpler building block. I was
hoping to use it *anywhere* you might have a list of values, not just
a WHERE clause. This is for my own programming convenience. I'm not
exposing a mini-SQL engine, I'm not programmatically generating entire
SQL statements. If I were, it's possible I would build something like
what you're proposing, but even then I would likely wind up writing
the simpler function anyway, because it would be handy as a building
block for more complex functionality.
John Y.
midrange.com
