Base types, Collections, Diagnostics, IO, RegEx…
The Orcas October CTP became available for download earlier this week. This CTP contains a couple new features from the BCL team:
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.
For those of you who are as acronymically challenged as myself, allow me to reveal that "CTP" is short for "Community Technical Preview."
I've downloaded & set-up the October CTP, but I can't find the named pipe support. What assembly & namespace is it in?
The new types are in System.Core.dll. HashSet is in System.Collections.Generic and the pipe types are in System.IO.
We'll probably be moving the pipe types to System.IO.Pipes for the next CTP.
HashSet is a new generic collection that has been added to the System.Collections.Generic namespace.
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.
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>.
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.
Is there a way to combine these two into a HashPipe? ;)