Fully dynamic d by opDotExp overloading

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Apr 17 22:27:25 PDT 2009


Nick Sabalausky wrote:
> "Daniel Keep" <daniel.keep.lists at gmail.com> wrote in message 
> news:gsbini$dga$1 at digitalmars.com...
>> Steven Schveighoffer wrote:
>>> ...
>>>
>>> I think Nick's point number 2 is that you would have to write the above 
>>> as:
>>>
>>> void twix(T)(T value)
>>> {
>>>       value.invokeMethod("bar");
>>>       value.invokeMethod("bar");
>>> }
>>>
>>> which would work whether bar was dynamically or statically defined.
>> So we have to write ALL templated code that calls member functions or
>> accesses properties/fields like this?
>>
> 
> No, only ones that absolutely need to work with dynamic classes. Which is 
> neither all nor the majority. Though dynamic invokation can absolutely be 
> useful at times, it is, and absolutely should remain, a fringe case.

But you're getting it exactly, almost rigorously, backwards. Algorithms 
specify an interface (e.g. implicit in the case of std.algorithm). The 
proposed feature allows the few to conform to the many, so the onus is 
exactly where it should.

>> Because otherwise objects may as
>> well not be able to do this, since it wouldn't play with any templates 
>> ever.
>>
>> You have to be joking.
>>
> 
> Joking about keeping my static guarantees? When the only other thing at 
> stake is a little bit of syntactic sugar on some occasional dynamic code? 
> Not a chance.

Some people said quite the same thing about virtual methods. They said 
it's a really stupid idea because now you can't test code - who knows 
what the callee is going to do? They could throw, do the wrong thing, 
etc. They said virtual methods break all guarantees and undermine static 
typing. They also weren't kidding, and they also were "right". Well, I 
guess they were kinda missing the point :o).


Andrei



More information about the Digitalmars-d mailing list