Following a trail that led from Mark's Excellent article on System.Xml version 2.0 features to Craig's post about a comment from Ian
The gist of it is that generics are not CLS Compliant - and this kind of makes sense as it would force all .NET languages to implement consuming of generics. However, the knock on effect of this is that much of the BCL API won't benefit from genericization (I think I'll patent that word).
I think that this shows an example where components should give access to their functionality via CLS compliant methods, but also support generic methods that can be consumed more efficiently by those langauges that support them (this would remove a whole bunch of casting for thos languages). But of course you also want the assembly marked as CLS Compliant and this can be acheived via the [CLSCompliant] attribute. But his would choke on the generic bits. However you can turn off CLS compliance checking on a member by member basis like this.
using System;
[assembly: CLSCompliant(true)]
public class Foo
{
public object Bar(Type t)
{
return Activator.CreateInstance(t);
}
[CLSCompliant(false)]
public T Bar() where T:new()
{
return new T();
}
}
So we have one version of the
Bar method is for langauges that only support the CLS the other is for those that support generics.
Hmmm ... this seems strangely reminiscent of Dual Interfaces which allowed COM interafces to be both scripting language friendly (IDispatch) and also v-table bound.