OSNews

I'm genuinely curious: what'd be a more elegant solution, in your opinion?

Well, templates/generics aren't really needed in a dynamically typed language.

Of course, a lot of people prefer static languages, in which case I suppose you would need some sort of generics construct, so I guess they aren't inelegant in the context of static languages.

I have found C# generics to be very useful and elegant solution for writing class libraries, frameworks etc. Once you are used to generics way of coding, its hard to not use it.

Are there other solutions the solve the problems that generics solve?

ccknight beat me to the question, and I'm honestly curious as well. The learning curve for generics is dead simple compared to templates, and IMO it's a very elegant solution since the compiler does all of the work for you as far as type safety checks go. I've yet to see it's equal in other languages.

C++ templates are probably its only saving grace; the language is otherwise without any redeeming value due to its overwhelming bug-inducing complexity. It's hard to not like the idea of parameterized types, and it should be hard to not like many of the features present in C++ that are usually missing in other languages like specialization and partial specialization. D is also fairly respectable in this regard, but as we all suspect, it will never obtain any sort of popularity and so might as well not exist as far as the average programmer is concerned.

C#'s generic facilities suffer too much from their Java++ nature: they should have been part of the language from the beginning and used throughout the framework. That and some brain damage like using signed integers as the basis for indices and other such things where negative values make no sense and require manual error-handling to toss out superfluous exceptions so as to obtain interoperability with VB.NET are just some of the many reasons the .NET framework doesn't impress me terribly. Blub, indeed.

Let's say that you want to create a class with a type parameter with the constraint that operator +, operator -, operator /, and operator * are defined. So you create an interface IArithmetic but you can't create instances with int or long as type parameters, because they do not implement the IArithmetic interface. Now you could handle this sort of type resolution structurally (which goes against the inheritance model of C#) or you can define an interface so that any kind of native numeric type can be the type parameter because someone is bound to want this. The former is the better solution, but not doing the latter is just retarded because your generic code can't deal with those types. Without specialization, you can't even shoe-horn it together so that the consumer of your library can just use it without caring that you've had to duplicate your effort because your development environment is retarded.

Another failing of C# generics is the absence of a feature like a "typedef" that would permit you to export instantiations of a parameterized type with a given type parameter with some typename. You can make your consumer create lots of ad-hoc typenames via the using keyword, but making your client's life difficult by making them type in SomeClass<SomeType, SomeType2<SomeType> > somewhere in their source file when they don't need to know/care that you were able to express your code generically is hardly advantageous.

Now these are just off the top of my head. I'm sure if I were to think about the issue I could come up with other topical weaknesses.

It's hard to not like the idea of parameterized types, and it should be hard to not like many of the features present in C++ that are usually missing in other languages like specialization and partial specialization.

The idea of parameterized types is just dandy. Sane uses of it, like the STL, are great. It's the idea of perverting the feature to serve as a macro system that bothers me. I didn't use to feel this way, but the more I used stuff like Boost the more it pissed me off. That and the god-aweful syntax, which is hard for both humans and compilers to parse...

Let's say that you want to create a class with a type parameter with the constraint that operator +, operator -, operator /, and operator * are defined. So you create an interface IArithmetic but you can't create instances with int or long as type parameters, because they do not implement the IArithmetic interface

What makes this even more fun is that in c# operators are static and interfaces do not contain static members.

To get around this you end up having to definine an IOperations<T> interface and provide implementations of Add, Subtract, etc for each numeric type.

Then you can create a Number<T, O> where O : IOperations<T> that defines all the regular operators and then you can finally write:

public T Add<T, C>(T a, T b) where C : IOperations<T>
{
Number<T,C> a2 = a;
Number<T,C> b2 = b;
return a2 + b2;
}

...

int c = Add<int,Int32Ops>(10, 5);

Yay.... This article goes into more detail: http://www.osnews.com/story.php?news_id=7930