Community

Andrei Alexandrescu pisze:
> We're trying to make that work. D is due for an operator overhaul.
>
> Andrei
Is there any chance that we get possibility to overload "raw operators",
like in C++? I think that they may coexist with currently defined
operator overloads with simple semantic rules, which will not allow them
to work together at the same time.
I know that they may obfuscate code, but they are extremely useful when
defining in D domain specific languages. For example I try to make SQL
expressions work as D expressions:
string query = "SELECT * FROM a WHERE id=5;";
-->
Query query = Select(a).Where(Equals(id, 5));
* "id" is D object in second expression
This translation is quite awful and unreadable. It would be so much
better to get:
Query query = Select(a).Where(id == 5);
With implicit casts there will be perfect environment, to define DSL-s
*in* D and *not* using unsafe strings.
BR
Marcin Kuszczak
(aarti_pl)

aarti_pl Wrote:
> Andrei Alexandrescu pisze:
> > We're trying to make that work. D is due for an operator overhaul.
> >
> > Andrei
>
> Is there any chance that we get possibility to overload "raw operators",
> like in C++? I think that they may coexist with currently defined
> operator overloads with simple semantic rules, which will not allow them
> to work together at the same time.
>
> I know that they may obfuscate code, but they are extremely useful when
> defining in D domain specific languages. For example I try to make SQL
> expressions work as D expressions:
>
> string query = "SELECT * FROM a WHERE id=5;";
> -->
> Query query = Select(a).Where(Equals(id, 5));
>
> * "id" is D object in second expression
>
> This translation is quite awful and unreadable. It would be so much
> better to get:
>
> Query query = Select(a).Where(id == 5);
>
> With implicit casts there will be perfect environment, to define DSL-s
> *in* D and *not* using unsafe strings.
>
> BR
> Marcin Kuszczak
> (aarti_pl)
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));

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

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.

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
* when moving Query around in program you will not be able to make it
typesafe, because it is just string
* 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...
BR
Marcin Kuszczak
(aarti_pl)

dennis luehring pisze:
>> ...
>> 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
>
Please see additional points, which I put into answer for Ary.
BR
Marcin Kuszczak
(aarti_pl)

> Autocompletion and syntax coloring.
ok one reason - but is the sql syntax not crippled enough using
operators - better if colored/autocompleted?
what does coloring help here
select
x,
y = (select u from b where ... ),
from select( xyz from abc )
left join
in the special case of inner selects, from selects, left/right/inner
joins...
the ultimate++ solution just works for very very simple statements
the readability is flying away
i personaly whould throw away the idea of getting functional style
programming like sql into an imperative language using operator
overloading or better -> i would not ask for more operator overloading
features based on this need :-)
what about other domain-specific languages like the blade stuff
or an ebnf parser (dparser?) - should these be more operator overloading
dependend for better coloring and auto-completion? i think operator
overloding is not the answer here
nothing agains autocompletion and syntax coloring - very much needed
decents smart autocompletion shows how it should be

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?
> * 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
> * 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

Denis Koroskin pisze:
> Slightly off-topic.
>
> How would you implement, say, LIKE condition? Similar to the following, perhaps:
> Query query = Select(a).Where(id.Like("%substring%"));
Well, probably:
...Like(id, "substring")...
In this case I prefer this kind of syntax more than OO kind of syntax :-)
> You could implement "==" the same way:
> Query query = Select(a).Where(id.EqualsTo(5));
In fact LIKE is not as a big problem as other operators. You will rather
not use nested LIKEs, but only the simplest form.
The best solution would be to introduce into language concept of infix
operator, so that any symbol could be such an operator. It would be most
universal solution. But it would be probably too much to ask...
Completely different situation than with LIKE is with comparison and
logical operators. They form very complicated expressions eg.:
Where(Or(And(Equals(surname, "Smith"), NotEquals(age, 25))),
And(Equals(surname, "Neo"), NotEquals(age, 50)))
With my syntax it would be:
Where((surname == "Smith" && age != 25) || (surname == "Neo" && age != 50))
I don't know how to write it using your syntax, because I don't have
good idea for AND/OR.
But the most important argument is that syntax, where operators are
parts of classes will cause unnecessary coupling of classes and concepts.
In my case objects which are used to identify columns are universal.
Using same identifiers you can also get values from resulting table.
When I implement parts of expression in Column classes I will loose this
decoupling: someone who just wants my resulting table object + column
identifiers will have to see api for sql expressions, which he/she will
not use at all.
Best Regards
(aarti_pl)