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