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.
