View mode: basic / threaded / horizontal-split · Log in · Help
December 23, 2008
Re: Operator overloading
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)
December 23, 2008
Re: Operator overloading
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...
December 24, 2008
Re: Operator overloading
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%";
December 24, 2008
Re: Operator overloading
> 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
December 24, 2008
Re: Operator overloading
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
December 24, 2008
Re: Operator overloading
> 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..
December 24, 2008
Re: Operator overloading
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
December 24, 2008
Re: Operator overloading
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
December 24, 2008
Re: Operator overloading
> 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
December 24, 2008
Re: Operator overloading
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.
1 2 3 4 5
Top | Discussion index | About this forum | D home