Share via


Orcas October CTP Now Available [Justin Van Patten]

The Orcas October CTP became available for download earlier this week.  This CTP contains a couple new features from the BCL team:

  • A new high performance set collection.

    HashSet is a new generic collection that has been added to the System.Collections.Generic namespace. It is an unordered collection that contains unique elements. In addition to the standard collection operations, HashSet provides standard set operations such as union, intersection, and symmetric difference.

  • New IO types that expose almost all pipe functionality provided by Windows.

    Pipes can be used to achieve inter-process communication (IPC) between any process running on the same machine, or on any other windows machine within a network. We've added managed support for both anonymous pipes and named pipes. Anyone familiar with streams should be comfortable using these new APIs to achieve IPC.

We'd love to get your feedback on these new features.  Download the CTP and let us know what you think.

We'll be blogging more about these new features going forward, including starter guides and design notes, so stay tuned!

Update: These new types are in System.Core.dll.  HashSet is in System.Collections.Generic and the pipe types are in System.IO.  Note: we'll probably be moving the pipe types to System.IO.Pipes for the next CTP.

Comments

  • Anonymous
    November 02, 2006
    For those of you who are as acronymically challenged as myself, allow me to reveal that "CTP" is short for "Community Technical Preview."

  • Anonymous
    November 02, 2006
    The comment has been removed

  • Anonymous
    November 03, 2006
    The comment has been removed

  • Anonymous
    November 08, 2006
    HashSet is a new generic collection that has been added to the System.Collections.Generic namespace.

  • Anonymous
    November 08, 2006
    I do not have the environment to test the latest CTP at the moment. With that in mind, is there documentation on the type available on MSDN? In particular I would like to know if HashSet<T> implements an ISet<T> interface? There are plenty of other types of sets. I do not expect Microsoft to provide them all. However, please enable the scenario for other developers such as myself. I recall the topic of ISet<T> being discussed previously (April / May?) on this blog.

  • Anonymous
    November 09, 2006
    There were several reasons why we ended up not including an ISet<T> interface.  First, we knew that we would only be adding one set implementation: HashSet.  Second, there was some uncertainty as to which methods actually belong on the interface.  We didn't want to get the design of ISet<T> wrong. There were also some other things like: cost, schedule, documentation, etc. In the end, like most things, leaving out ISet<T> was a trade off.  In the future, if we add another set implementation, we will likely also include ISet<T>.

  • Anonymous
    November 09, 2006
    Justin, Thank you for the response. > In the future, if we add another set > implementation, we will likely also > include ISet<T>. The main problem as I see with this though is that without a common interface from the start, methods will be defined taking a HashSet<T>. When you add a new set type and interface, the signatures for all of these methods will need to be either rewritten (time, testing) or replaced (depreciated, code bloat). I regularly use multiple types of sets. I would like to integrate them into the framework. However, if you do not provide an ISet<T> type, then all of my work in incompatible with yours. I can either continue to use mine and ignore the new HashSet<T>, or throw away mine types and be restricted to your single implementation. Neither option is very appealing. ISet<T> is a bridge between the two. I strongly appeal to you and your team to readdress the issue. "cost, schedule, documentation" are always issues. However, to be honest, I would rather wait until a future version and have no HashSet<T> until there is sufficient resources to design a proper ISet<T> model. More than anywhere else in the framework, data structures absolutely require well designed and defined interfaces. The interface should come before the actual class. Please rethink this.

  • Anonymous
    November 13, 2006
    The comment has been removed