On 1/1/16 6:30 AM, Russel Winder via Digitalmars-d wrote:
On Fri, 2016-01-01 at 10:40 +0000, Kapps via Digitalmars-d wrote:
[…]

Someone else can explain better / more correctly than me, but I
believe the issue lies with opCmp and opEquals. You can make
expressions like p.Name.equals("James") work (I believe using
opDispatch), but because all you have is opEquals, you can't know
if the user put in 'p.Name == "James"` or `p.Name != "James"`, as
they both simply call opEquals. In order to do that, you would
need things like opLessThan, opEquals, opNotEquals,
opGreaterThan, etc, which would (with improper use or bugs) cause
other issues, like a < b && a > b and a == b && a != b to be
true, or a == b || a != b to be false.

I'm also not certain how you could implement `p => p.Name ==
"James" || p.Name == "Bob"`, but there might be a way? I think
this is the gist of it, but I'm likely wrong on some aspects of
this, so it would be good if someone else clarified..

Hummm… so to put it another way, the D meta-object protocol is even
more broken than that of Java: at least in Java there isn't even a
pretence that you can create an internal DSL. This is very, very sad, I
had not realized D was this broken.

Well I guess it's time to cut losses and cancel that D tutorial at ACCU 2016, eh :o).

I understand how the shortcomings of D's expression templates (ETs) for SQL (as compared to C++ or LINQ) can be construed as an indication of a language breakage, but I don't quite agree for a few reasons.

One, D offers another mechanism aside from ETs for embedded domain-specific languages. So in a way there's less pressure on offering lush ET than would be in other languages.

Second, ET as a mechanism for SQL interface has other inherent limitations. Consider the "LIKE" operator in SQL, which has no ET equivalent in C++ with similar syntax, and no direct equivalent in LINQ. That doesn't mean the respective languages are broken.

Third, evaluating the merits and demerits of a language choice should be done within several appropriate use cases, not just one. For example, D's use of opEquals/opCmp saves a lot of boilerplate and potential bugs in many cases compared to C++. On another example, C++'s overloading of &&, ||, and the comma operator are considered downright disastrous and are unrecommended by virtually all coding standards and guidelines, yet do work with ETs.


Andrei

Reply via email to