dsimcha wrote:
== Quote from Yigal Chripun (yigal...@gmail.com)'s article
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.
Simplicity and DRY--you only need to specify what the compiler doesn't already
know.
simplicity - have one syntax to remember instead of two.
DRY - concepts are already present and used, see the isXXXRange
templates. I didn't add anything beyond that.
