aarti_pl wrote:
Don pisze:
aarti_pl wrote:
Don pisze:
There's been some interesting discussion about operator overloading
over the past six months, but to take the next step, I think we need
to ground it in reality. What are the use cases?
I think that D's existing opCmp() takes care of the plethora of
trivial cases where <, >= etc are overloaded. It's the cases where
the arithmetic and logical operations are overloaded that are
particularly interesting to me.
[snip]
But I know of very few reasonable non-mathematical uses.
In C++, I've seen them used for iostreams, regexps, and some stuff
that is quite frankly bizarre.
So, please post any use cases which you consider convincing.
DSL support in mother language. As an example I can give SQL in D or
mockup tests description language (usually also in D - not as a
separate script language).
Could you be more specific about this? For SQL, arithmetic and logical
operators don't seem to be involved.
In fact they both can be involved. Below are operators which are
understood by SQLite - one of the simplest databases:
Binary:
||
* / %
+ -
<< >> & |
< <= > >=
= == != <> IN LIKE GLOB MATCH REGEXP
AND
OR
Unary:
- + ~ NOT
As you see there are arithmetic operators and as well logical operators,
which are used in SQL expressions.
The example you gave showed (if I understand correctly) a wish to make
expression templates involving comparison operators, a task which is
currently impossible.
Why do you mention expression templates? Its not necessary to use them
in my opinion. Operator overloading should be just right for this task.
It seems to be the same concept: the == operator does not perform an ==
comparison, rather the return value records the operands which were
used, and records the fact that an equality comparison needs to be made.
The actual equality comparison is done later, when the complete
expression is known (it is done in the SQL statement).
I see built-in operators overloading as a part of wider category of
defining infix functions (eventually also postfix functions).
It seems to be a case where you want an abstract syntax tree.
Also I would like to add a word to my latest post regarding string
mixins as I see I was not clear enough about it. It should be possible
to construct queries itself on runtime like below:
DbTable Person = ....; //In my case DbTable keeps table columns and few
other informations
DbMatrix getPersons(SQLExpression exp) {
Query query = Select(Person).Where(exp);
return Database.execute(query);
}
void main() {
SQLExpression exp = (Person.Name == "John");
DbMatrix res = getPersons(exp);
}
This is what I mean by constructing queries on runtime. With string
mixins you will have to do not only mixin(SQL("SELECT ....")) but also
mixin(SQLExpression()), what gets really complicated in the end.
No. You can always move the complexity into the mixin string parser.
(since you can get full type information of everything mentioned in the
string).
BTW, the string mixin is just a temporary evil -- it's a way of getting
an abstract syntax tree using existing D. It's severely lacking syntax
sugar.
