aarti_pl wrote:
Lutger pisze:
yigal chripun wrote:
aarti_pl Wrote:
....
There's nothing more hideous than all those frameworks in Java/C++ that
try to re-enginer SQL into functions, templates, LINQ, whatever. SQL
*is*
a perfectly designed language for its purpose and it doesn't need to be
redisnged! The only problem with this is the type-safety when embedding
sql as string in a host language. the solution is two-phased:
I disagree. There are a couple of problems with using Sql strings
inside regular code:
- no help from the IDE whatsoever. Imagine writing your D program in
notepad, then instead of compiling it in advance, you compile it at
runtime: losing all benefit from the static type checking and whatever
the IDE offers you (highlighting and autocomplete). This would be
completely absurd yet you prefer it with sql? Of course you can write
queries in a specialized environment, somewhat better but it also sucks.
Thanks for this post. It is basically answer to other (rather
dismissive) posts.
In addition to what you said, you get from IDE also possibility to
refactor your database columns/names/types etc. All with static checks
in your code. After change you know immediately what should be changed.
(*it is possible at least in my framework, I don't know if it is
possible in other frameworks).
Yes, I think IDE integration is one of the biggest issues facing macros.
Additionally in my framework you can pass around parts of SQL e.g. :
WhereExpression exp = Where(More(visitcards.id, 100));
You basically *CAN NOT* do it when just using strings.
Of course you can define a where clause using strings.
(I'm not sure when you'd want to, though. I suspect that the fact that
you can do it in your framework, is an implementation detail rather than
a design goal. It's easy to think of uses for run-time generated naked
WHERE clauses, but much harder for compile-time ones).
phase a is simple, look at the C# API for postgres (I think). The
query is
one string like: "select * from table where :a > 42", the :name is a
place
holder for the host-language variable, and you call an API to bind those
:names to variables in a type-safe way. the downside is that it's
verbose.
phase b is what Nemerle does with the above - it has an AST macro to
wrap
the above so you can write your query directly and it is checked as
compile-time.
No operators were abused in implementing this.
I fail to see how this is any different than Linq. Granted, you just
reproduce the SQL language and ignore any mapping to Objects, but
other than that it is just the same but with a different technology.
That *is* the difference! It's exactly what you'd do in a run-time API,
but it is checked at compile time. IMHO, the ideal for metaprogramming
is that you can hardly tell that you are using it. (BTW, that's why I'm
a huge fan of CTFE).
(Linq is not only about abstracting sql by the way, it does a lot more)
I would like to add that probably many of DSL languages would never be
created if mother languages would be expressive enough.
Yes, I've worked with some DSLs for which that was definitely true.
And additionally, can any of opponents explain what is so wrong with
operator overloading suggested by me in last emails? (Pseudocode - I
didn't check exact syntax):
RES opInfix(alias str)(T val) {
...
}
...
auto expr = Where((visitcards.id `>` 100) `AND` (visitcards.surname
`Like` "A*"));
(Please note that when overloaded operator is used it is denoted with ``
(it can be probably any definition of string). I think it would be good
enough solution and thanks to this operator overloading will be clearly
visible in calling code).
`AND` is not operator overloading in the traditional sense. This is
something else. You're proposing a whole new infix notation, and it's
difficult to evaluate it without knowing how it would work.
I don't understand why `Like` is an operator, but `Where` is not. You
haven't addressed operator precedence.
And I still don't think it looks terribly good for SQL. With:
id `>` 100
users would always be thinking, "why can't I just write id > 100 ? That
` is so annoying!"
