Short list with things to finish for D2

[aarti_pl]

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).

> - mapping relational data to objects is a sucky, boring, lengthy and error 
> prone task.
> In my experience a simple ORM tool such as Linq-to-Sql makes life so much 
> easier. RoR has this too, it's a blessing.
> 
> Now if you want to do a big part of your logic on the database instead of 
> simply using it as storage, that may be a different story. (I still think it 
> sucks though)

Well, I have different view on this. Personally I think that it is much 
better (faster, easier) to pass tables in the application.

But after defining SQL query (in object oriented way) you can do 
whatever you want: you can change your SQL object into table of data or 
into objects.

You can also use these object oriented queries to generate different SQL 
dialects for different databases or you can generate hashes for using 
them as keys in your cache.

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. So I think such a 
way of defining DSLs in mother language have its merits. String is not 
enough.

>> 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. (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.

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 dear opponents please propose how to solve above mentioned problems 
with DSL languages as strings ;-) If there will be a way to solve all 
those problems cleanly - I am all for not using operator overloading :-)

Best Regards
Marcin Kuszczak