yigal chripun wrote:
Lutger Wrote:
Yigal Chripun wrote:
On 19/12/2009 01:31, Lutger wrote:
Yigal Chripun wrote:
On 18/12/2009 02:49, Tim Matthews wrote:
In a reddit reply: "The concept of templates in D is exactly the same
as in C++. There are minor technical differences, syntactic
differences, but it is essentially the same thing. I think that's
understandable since Digital Mars had a C++ compiler."
http://www.reddit.com/r/programming/comments/af511/ada_programming_generics/c0hcb04?context=3
I have never touched ada but I doubt it is really has that much that
can't be done in D. I thought most (if not all) the problems with C++
were absent in D as this summary of the most common ones points out
http://www.digitalmars.com/d/2.0/templates-revisited.html.
Your thoughts?
I don't know Ada but I do agree with that reddit reply about c++ and D
templates. D provides a better implementation of the exact same design,
so it does fix many minor issues (implementation bugs). An example of
this is the foo<bar<Class>> construct that doesn't work because of the
">>" operator.
However, using the same design obviously doesn't solve any of the deeper
design problems and this design has many of those. An example of that is
that templates are compiled as part of the client code. This forces a
library writer to provide the source code (which might not be acceptable
in commercial circumstances) but even more frustrating is the fact that
template compilation bugs will also happen at the client.
Well yes, but the .NET design restrict the generic type to a specific
named interface in order to do type checking. You may find this a good
design choice, but others find it far more frustrating because this is
exactly what allows for a bit more flexibility in a statically typed
world. So it is not exactly a problem but rather a trade-off imho.
The .Net implementation isn't perfect of course and has a few issues
that should be resolved, one of these is the problem with using
operators. requiring interfaces by itself isn't the problem though. The
only drawback in this case is verbosity which isn't really a big deal
for this.
The drawback is not verbosity but lack of structural typing. Suppose some
library has code that can be parametrized by IFoo and I have another library
with a type that implements IBar, which satisfies IFoo but not explicitly
so. Then what? Unless I have totally misunderstood .NET generics, I have to
create some proxy object for IBar that implements IFoo just to satisfy the
strong type checking of .NET generics. You could make the argument that this
'inconvenience' is a good thing, but I do think it is a bit more of a
drawback than just increased verbosity.
The way I see it we have three options:
assume we have these definitions:
interface I {...}
class Foo : I {...}
class Bar {...} // structurally compatible to I
template tp (I) {...}
1) .Net nominative typing:
tp!(Foo) // OK
tp!(Bar) //not OK
2) structural typing (similllar to Go?)
tp!(Foo) // OK
tp!(Bar) // also OK
3) C++ style templates where the compatibility check is against the *body* of
the template.
of the three above I think option 3 is the worst design and option 2 is my favorite design. I think that in reality you'll almost always want to define such an interface and I really can't think of any useful use cases for an unrestricted template parameter as in C++.
You forgot option 4:
4) D2 constrained templates, where the condition is checked inside the
template constraint.
This is more powerful than option 2, because:
(1) there are cases where you want MORE constraints than simply an
interface; and (2) only a subset of constraints can be expressed as an
interface.
Also a minor point: (3) interfaces don't work for built-in types.
Better still would be to make it impossible to compile a template which
made use of a feature not provided through a constraint.
