Does D have too many features?

[F i L]

On Saturday, 28 April 2012 at 23:54:36 UTC, Peter Alexander wrote:
> On Saturday, 28 April 2012 at 23:37:14 UTC, F i L wrote:
>> Peter Alexander wrote:
>>>> - opDispatch
>>>> This is useful and of significant value if used the right 
>>>> way.
>>>
>>> Can you give me an example of it being used the right way?
>>
>> It can be very useful for jQuery/JSON style dynamic objects:
>>
>>    import std.variant, std.stdio;
>>
>>    struct Dynamic {
>>        Variant[string] vars;
>>
>>        void opDispatch(string key)() @property {
>>            return vars[key];
>>        }
>>
>>        void opDispatch(string key, T)(T value) @property {
>>            vars[key] = value;
>>        }
>>    }
>>
>>    void main() {
>>        auto foo = Dynamic();
>>
>>        foo.a = "A";
>>        foo.b = 11;
>>
>>        writefln("%s, %s", foo.a, foo.b);
>>    }
>
> This is a perfect example of misuse.
>
> Glancing at that code, it looks like foo has two member 
> variables. It is also not clear that each access involves a 
> hash-table lookup.
>
> Why abuse well-understood syntax when there are simpler ways to 
> solve the problem?

It's not abuse, it's design. That's why I called the type 
"Dynamic" so the user has an idea about what it is. You could 
make your same arguments against ever using a Variant object. 
When you have to manipulate a DOM or XML tree, there's reason why 
people prefer languages that syntactically interface with those 
dynamic structure very well. D simply powerful enough to provide 
a way for programmers to do both.

Btw, it's just as unclear that any @property (or function) 
doesn't look through a hash-table or any other number of 
performance pitfalls if used without any insight into _how_ to 
use it. This is why we have documentation for libraries, it's 
impractical cater the language to the idea that coders wont 
understand the objects their working with to a basic degree.


>>>> I hope you are not actually serious about that '->' part.
>>>
>>> I'm serious. I don't like overloaded syntax.  foo.bar 
>>> shouldn't also mean (*foo).bar -- it causes confusion and 
>>> introduces ambiguities when either could work. Combine this 
>>> with opDispatch, UFCS and function overloading and your in 
>>> for some nasty headaches.
>>
>> Craziness. What could you possibly gain is there in forcing a 
>> pointer distinction at every point that it's used? We already 
>> declared the variable as a pointer, we don't need to be 
>> reminded of that fact at every line.
>
> It matters when you have things that imitate pointers (e.g. 
> smart pointers). Those will have their own members, separate 
> from the pointee's members, so ptr.foo could refer to the smart 
> pointer's members or the pointee's members.

SomeDude said this best. This is far the common case, and the 
language shouldn't force everyone to pay for this situation.