dsimcha wrote:
== Quote from bearophile (bearophileh...@lycos.com)'s article
Yigal Chripun:
point in case, look how much
unnecessary confusion Ranges cause which would be eliminated had D
allowed for compile-time interfaces.
What are interfaces from the point of view of the compiler?
Abstract classes with only pure virtual functions. In other words, basically
under the hood, an interface is just the layout of a vtable.
That's run-time interfaces. compile-time interfaces are like C++ concepts.
This actually leads to a comment I want to make in the wider debate: I
personally
find explicit interfaces really, really annoying and I think that duck typing is
by far the most intuitive type system there is. I used to program primarily in
duck typed languages and resort to every kludge imaginable for speed. What
attracted me to D was that the templates and type inference are so powerful
that I
almost feel like it's still a duck typed language, but much faster and with more
error checking. I guess that's why I like ranges so much.
duck-typing has its benefits, that's for sure. it all boils down to is
style issues I guess - do you prefer implicit or explicit interfaces.
either are fine by me, even though it seems to me that duck-typing is
more of a dynamically typed language feature but maybe my feeling here
is wrong.
either way, the language needs to be consistent about it in order to not
confuse users unnecessarily.
Also, while the fact that you need interfaces to specify a vtable layout is an
implementation detail, I would argue that, in close to the metal languages, it
does more harm than good to try too hard to prevent implementation details from
leaking into the language abstractions. Otherwise, what would be the point of
it
being a close to the metal language? The fact that, for templates, one does not
need to specify vtable layouts and for OO you do justifies the asymmetry between
templates and OO. Interfaces for templates would just add boilerplate and make
explicit something that is already implicitly knowable and checked at compile
time
anyhow.
here I disagree. it sometimes makes sense to let implementation details
leak into your abstractions when you gain something by it, like
performance (e.g. "Worse is better" principle) but I don't see how this
applies here. what is there to gain by doing this compromise in this case?
there is no added performance since it's all compile-time, there is no
additional flexibly like with run-time duck-typing.
