Proposal: Database Engine for D

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Sun Jan 3 16:49:29 PST 2016


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



More information about the Digitalmars-d mailing list