dennis luehring pisze:
> aarti_pl schrieb:
>> Ary Borenszweig pisze:
>>> dennis luehring escribió:
>>>>> ...
>>>>> This translation is quite awful and unreadable. It would be so much better to get:
>>>>>
>>>>> Query query = Select(a).Where(id == 5);
>>>>
>>>> what speaks against an sql parsing mixin?
>>>>
>>>> would be more expressive, compiletime based and typesafe
>>>> and even far more be able than what you can do with operator overloading
>>>
>>> Autocompletion and syntax coloring.
> 
>> Yes. And additionally:
>> * you can not build safely your queries on runtime
> 
> that even not possible with operators - or?

It is possible and it works :-)
But with operator overloading it is so much more readable, than without it.

Creating queries at runtime is quite common:

age = 20;
string query = "Select name, surname FROM persons WHERE age = " + to!(string)(age);

>> * when moving Query around in program you will not be able to make it typesafe, because it is just string
> 
> not if you parse the string at compiletime an use the
> type information from outer scope for validation

Compile time checking of SQLs will not be enough for any bigger program.
How would you insert your data into database? INSERT needs values which are taken e.g. from GUI and completely unknown at compile-time.

>> * in my db access system it won't be possible to automatically create database, typesafely get results from resulting table and few other nice features...
> 
> just a quick look into blades (library with vector math language extensions - based on compiletime strings)
> 
> http://www.dsource.org/projects/mathextra/browser/trunk/blade/BladeDemo.d
> 
> don referes to outer vars in his "strings" and you can typecheck them

It doesn't solve all problems. Just a one.

BTW. In recent release Boost team added a whole brand new library for domain specific languages embedded languages called Proto. I think that it means that there is quite a big need for such features. E.g. for mocking frameworks which will also profit from extended DSL sublanguages support in programming languages.

BR
Marcin Kuszczak
(aarti_pl)

Ary Borenszweig escribió:
> dennis luehring escribió:
>>> ...
>>> This translation is quite awful and unreadable. It would be so much better to get:
>>>
>>> Query query = Select(a).Where(id == 5);
>>
>> what speaks against an sql parsing mixin?
>>
>> would be more expressive, compiletime based and typesafe
>> and even far more be able than what you can do with operator overloading
> 
> Autocompletion and syntax coloring.

And also, you get a nice compile error message if the query is malformed. With a mixin you might end up with a stack of hard-to-interpret error messages.

Finally, parsing strings is not easy, specially at compile time. And there's also the problem of lack of garbage collection at compile time...

Denis Koroskin wrote:
> Slightly off-topic.
> 
> How would you implement, say, LIKE condition? Similar to the following, perhaps:
> Query query = Select(a).Where(id.Like("%substring%"));
> 
> You could implement "==" the same way:
> Query query = Select(a).Where(id.EqualsTo(5));

downs way:
auto query1 = select(a) /where/ "id" /eq/ 5;
auto query2 = select(a) /where/ "name" /like/ "%bob%";

> It is possible and it works :-)
> But with operator overloading it is so much more readable, than without it.
> 
> Creating queries at runtime is quite common:
> 
> age = 20;
> string query = "Select name, surname FROM persons WHERE age = " + to!(string)(age);

that is not object + operator based - your flexibilty here comes from your string and the "runtime" interpretation of the sql semantic in your database ...

if you need an additional "LIKE" based on an codition you need to rebuild your object/operator concatination in complete:

if( gui.checkbox == true )
{
  SELECT a from b
}
else
{
  SELECT a from b WHERE c LIKE '% ~ C ~ %'
}

> Compile time checking of SQLs will not be enough for any bigger program.
> How would you insert your data into database? INSERT needs values which are taken e.g. from GUI and completely unknown at compile-time.

why is a value that comes from an gui not compile-time?
not the value is what you need - its the type (when we talk about type safetyness)

how does vector-array get into Don's Blade strings? and why do i get
compile-time errors when using the wrong type inside of the string?

and you can't even speak of type-safetyness when using only strings in your database communication - how can be your results typesafe
(i don't like string[string] results-set) because the safetiness is programatical

> BTW. In recent release Boost team added a whole brand new library for domain specific languages embedded languages called Proto. I think that it means that there is quite a big need for such features. E.g. for mocking frameworks which will also profit from extended DSL sublanguages support in programming languages.

you should read into the details of using mixins - they are much much more flexible than you think (not just boring strings) - and with the base feature-set of D something like mock wouldn't even exist
and what the boost guys to is to get around c++ base feature-set to express new thing with c++

@Ary does syntax coloring and smart auto-completen help while writing
spirit based parsers? the complete meaning of ( * - \ ... is different to "normal" code

btw: don syntaxtree is also an great example of using mixins
http://www.dsource.org/projects/mathextra/browser/trunk/blade/SyntaxTree.d

Ary Borenszweig schrieb:
 > Finally, parsing strings is not easy, specially at compile time. And
> there's also the problem of lack of garbage collection at compile time...

ok thats 140% true

but i think that using mixins to embedd domain-spec-lang into D is currently the best way doing it (except the compiler bugs around)
the only other thing on my radar is the "ast-macro" feature walter,andrei,.... are talking about

> the ultimate++ solution just works for very very simple statements
it works for every query. You can write for example:
Select(PRODUCTS[ID], CUSTOMER[NAME])
.From(PRODUCTS)
.InnerJoin(CUSTOMERS)
.On(CUSTOMERS[PRODUCT_ID] == PRODUCTS[ID] && Like(PRODUCTS[NAME], "BOOK%"))
.Where(PRODUCTS[ID] > 10);

You can have another statement in where or even in select..

Uno schrieb:
>> the ultimate++ solution just works for very very simple statements
> it works for every query. You can write for example:
> Select(PRODUCTS[ID], CUSTOMER[NAME])
> .From(PRODUCTS)
> .InnerJoin(CUSTOMERS)
> .On(CUSTOMERS[PRODUCT_ID] == PRODUCTS[ID] && Like(PRODUCTS[NAME], "BOOK%"))
> .Where(PRODUCTS[ID] > 10);
> 
> You can have another statement in where or even in select..

and "from select"

btw: i don't want to say: "its not possible" - i want
to say: "it is even clear to handle in D" without going the no-other-way-in-c++ solution

dennis luehring escribió:
>> It is possible and it works :-)
>> But with operator overloading it is so much more readable, than without it.
>>
>> Creating queries at runtime is quite common:
>>
>> age = 20;
>> string query = "Select name, surname FROM persons WHERE age = " + to!(string)(age);
> 
> that is not object + operator based - your flexibilty here comes from your string and the "runtime" interpretation of the sql semantic in your database ...
> 
> if you need an additional "LIKE" based on an codition you need to rebuild your object/operator concatination in complete:
> 
> if( gui.checkbox == true )
> {
>   SELECT a from b
> }
> else
> {
>   SELECT a from b WHERE c LIKE '% ~ C ~ %'
> }
> 
>> Compile time checking of SQLs will not be enough for any bigger program.
>> How would you insert your data into database? INSERT needs values which are taken e.g. from GUI and completely unknown at compile-time.
> 
> why is a value that comes from an gui not compile-time?
> not the value is what you need - its the type (when we talk about type safetyness)
> 
> how does vector-array get into Don's Blade strings? and why do i get
> compile-time errors when using the wrong type inside of the string?
> 
> and you can't even speak of type-safetyness when using only strings in your database communication - how can be your results typesafe
> (i don't like string[string] results-set) because the safetiness is programatical
> 
>> BTW. In recent release Boost team added a whole brand new library for domain specific languages embedded languages called Proto. I think that it means that there is quite a big need for such features. E.g. for mocking frameworks which will also profit from extended DSL sublanguages support in programming languages.
> 
> you should read into the details of using mixins - they are much much more flexible than you think (not just boring strings) - and with the base feature-set of D something like mock wouldn't even exist
> and what the boost guys to is to get around c++ base feature-set to express new thing with c++
> 
> @Ary does syntax coloring and smart auto-completen help while writing
> spirit based parsers? the complete meaning of ( * - \ ... is different to "normal" code

I was thinking about LINQ, specifically. Ok, LINQ is too much (and too specific), I wouldn't like something like that in D, but something similar...

> 
> btw: don syntaxtree is also an great example of using mixins
> http://www.dsource.org/projects/mathextra/browser/trunk/blade/SyntaxTree.d

> I was thinking about LINQ, specifically. Ok, LINQ is too much (and too specific), I wouldn't like something like that in D, but something similar...

my point is that operator overloading helps only i a very few cases - and even then (see syntaxhighliing in boost::spirit based parsers) it does not realy help

but it think (again, except the compiler bugs) D is be able to do something like LINQ (as an example) with mixins (or ast-macros) without
the need of extending the language itselfe - only the parsing on compiletime thing needs to be easier - but any solution(s) in this part of D will also help all other generic library developers

dennis luehring Wrote:

> Uno schrieb:
> >> the ultimate++ solution just works for very very simple statements
> > it works for every query. You can write for example:
> > Select(PRODUCTS[ID], CUSTOMER[NAME])
> > .From(PRODUCTS)
> > .InnerJoin(CUSTOMERS)
> > .On(CUSTOMERS[PRODUCT_ID] == PRODUCTS[ID] && Like(PRODUCTS[NAME], "BOOK%"))
> > .Where(PRODUCTS[ID] > 10);
> > 
> > You can have another statement in where or even in select..
> 
> and "from select"
> 
> btw: i don't want to say: "its not possible" - i want
> to say: "it is even clear to handle in D" without going the
> no-other-way-in-c++ solution
> 

 I suppose you could do it that way, at least it would definately be readable rather than what i've seen in java (and ASP) before.

 query = "Select * from persons where firstname='"+fname+" and lastname='"+lname+" and age="+age+... ect.ect

 Recently i've started reading about lex and yacc (or flex and bison) and as a comment in there, it wouldn't be too hard to use substitution and have a pre-processor convert it into pure D code.

 SQLQuery("
Select * from persons
where firstname=%fname%
and lastname=%lname%
and age=%age%")

Just a thought.