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