Short list with things to finish for D2

[Don]

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!"