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)

On Wed, 24 Dec 2008 00:01:20 +0300, Ary Borenszweig <ary@esperanto.org.ar> wrote:

> 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 some compile-time checks (so that you don't mistype your tables/columns):

enum Artists
{
   Id,
   Name,
}

enum Albums
{
   Id,
   Name,
   ArtistId,
}

enum Songs
{
   Id,
   Name,
   AlbumId,
}

auto request = Select(Songs.Id, Songs.Name).
			From!(Artists).
				InnerJoin!(Albums).OnEqual(Albums.ArtistId, Artists.Id).
				InnerJoin!(Songs).OnEqual(Songs.AlbumId, Albums.Id).
			Where(Artists.Name).EqualsTo("Beatles").
			And(Albums.Name).EqualsTo("Yellow Submarine").
			OrderBy(Songs.Name).
			Limit(0, 1);

Just an example :)