Udostępnij za pośrednictwem


Generics CLS compliant in Whidbey

I am super excited about the fact that generics will be CLS complaint for Whidbey… With this change generics are now completely first class in Whidbey… It means that the frameworks Microsoft and 3rd parties produce can full leverage this new feature in order to provide the most value to our customers. I would suggest you follow the Generics Design Guidelines when using generics in public APIs.

As always, we’d love to hear your feedback and comments on this. Is it a good change? Are there places in Whidbey that you’d like to see us use generics better?

Comments

  • Anonymous
    December 21, 2004
    The comment has been removed
  • Anonymous
    December 21, 2004
    GREAT CHANGE. As an ISV who provides frameworks and controls with our products, we won't be forced to decide between "rich vs reach" in our API design. As a veteran of the "ole automation debacle", back when Powerbuilder supported some but not all COM features, I'm very appreciative.
  • Anonymous
    December 21, 2004
    That Generics Design Guidelines link doesn't reflect the latest thoughts on type parameter naming (TKey, TValue instead of K,V), so I regard the rest of it as suspect too. Is there an official up-to-date copy of this document somewhere? If not, there should be.
  • Anonymous
    December 21, 2004
    The comment has been removed
  • Anonymous
    December 21, 2004
    Since generics cause code to be generated at run-time, doesn't this mean .NET applications will steadily become slower and slower in the future, especially at startup, as more and more libraries use generics? Why is no one talking about this potential problem with the basic design?
  • Anonymous
    December 21, 2004
    Frank, I wouldn't categorize this as a problem as much as a conscious design decision.

    We only JIT one unique type for all combinations of reference type arguments for a given generic type. Therefore, the only "bloat" is with value type arguments, and even then it’s not really a problem unless you start using every tons of permutation consisting of value types. (For example, Dictionary<int,int>, Dictionary<int,long>, Dictionary<float,int>, Dictionary<int,float>, and so on.)

    If this is unacceptable, there’s always NGen to avoid the time penalty of having to JIT at runtime... although you can't escape the (minor) working set hit.

    As I stated earlier, this is a conscious design decision resulting from our use of type generation instead of erasure. You should read JoelPob's excellent article on this very topic for more information: http://blogs.msdn.com/joelpob/archive/2004/11/17/259224.aspx.
  • Anonymous
    December 21, 2004
    -- quote -- I'd like to see a WinForms control that was a generic type and the value property could be set based on the generic type -- quote -- .

    Sounds like the <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnavalon/html/avalon07072004.asp">Avalon content control</a>
  • Anonymous
    December 21, 2004
    I'd like to see DataSets (especially typed DataSets) using nullable types.
  • Anonymous
    December 29, 2004
    All I want is a typedef statement in C# ( or its equivalent ) so that I don't have to deal with the angle brackets if I don't want to. I don't mind using generics at all I just want to be able to refer to:

    ArrayList<People>

    as

    PeopleList

    with the declaration looking oh so similar to C++:

    typedef ArrayList<People> PeopleList;

    Is this too much to ask at this late stage in the game?
  • Anonymous
    December 31, 2004
    I worry about a compile time only solution as you quickly end up needing the symbolic name when debugging, in static representations (such as config files), via reflection, etc.
    But you can always do this if you’d like:

    public class PeopleList : List<People> { }

    I think it gives you most of what you want.

  • Anonymous
    January 03, 2005
    Lonnie, you can do that like so:

    public class PeopleList : List<People> {}

    This leaves you open to define other methods for the PeopleList class as well.