aarti_pl wrote:
Don pisze:
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);
I think that's still awful. I prefer:
Query query = mixin(SQL("SELECT * FROM a WHERE id=5"));
>
Thanks for example - it talks to me more than 1000 words :-)
Your proposal is indeed interesting. (And I think it is what Dennis
Luehring was reffering to).
But I have to say it has some drawbacks. Let me enumerate them:
1. Extending such a queries on runtime would be rather difficult IMHO,
and will not look very nice. With my solution you can do something like
this:
---
Column cols = [person.name, person.surname, person.nick];
for(i=0; i<rows; i++) {
InsertStatement insert = Insert();
foreach(Column col; cols) {
insert ~= insert.insert(col, getText(i, col));
}
db.execute(insert);
}
* example not tested, but something like this is already possible in my
framework.
Constructing queries dynamically is very useful for creating e.g.
universal gui controls which could be just binded to database tables.
Another useful example is sending SQL expression (not the whole
statement) as an argument to function.
To make it work nicely with mixins IMHO you will have to make this kind
of SQL to look much uglier than in this simple case.
Do you have any proposals how it could look like with mixins?
There's nothing stopping you from using local variables in the mixin
string. A simple possibility is to use $ for embedded variables. (You
can avoid that, but it's much more difficult, and has some minor
downsides, you can't have use a local variable called 'select', for
example).
I pretty much got this working for BLADE, but the CTFE memory bug makes
it completely unusable at present.
2. I see also problem with IDE-s which will have to be changed to
understand DLSs in mixins. I think that it is doable and even can be
done quite nice, but currently there is *no* support for such a feature.
It means that you will not have:
a. syntax highlighting
b. no IDE proposing your names of variables and methods
c. no refactoring
That's true, and indeed very difficult to solve.
3. Sometimes having more expressiveness in language can avoid creating
new DSLs. I think it is a Good Thing (tm). In fact I took that way and
decided to integrate SQL DSL language into mother language. That way
programmers don't have to learn new syntax, but just use existing syntax
of mother language to solve specific problems. Using DSL in mother
language resolves then into just writing special kind of API, which can
be used in standard way to achieve goal. D and most other languages from
C family are almost perfect candidates to make something like this with
SQL.
So while I can agree that original SQL looks much better than any kind
of its imitation, I think that it is not necessary better for productivity.
That's a worthwhile criticism of DSLs in general.
