Just a general curiosity question. Why is this namespace "System.Collections.Generic" added by default in Visual Studio when we create the project instead of let's say "System.Collections"?
Is Collection Classes under generics is most preferred way than the Collection Classes in the System.Collections?
Thanks
Harsha
Yes, generics collection are better than regular collection because they bring strong typing, which prevent boxing and unboxing, and all those annoying casting.
There are few reason left to use a regular collection. Even if you don't know which type of object that you are storing, you can still use something like List<object>.
Generic collections are far easier to use and it makes sense to me to have them included by default.
.NET 2.0 added generic collections, which should completely replace the use of the non-generic collections in applications built for .NET 2.0 and beyond.
They have many advantages, especially since they bring strong typing and avoid boxing of value types.
As for why the namespace is added by default - I'd guess Microsoft decided to add this to encourage their use instead of the older System.Collections classes.
I suspect that if MS released the .NET BCL with the generic collection classes, many of the non-generic versions would not have been included.
Having said that, there is quite a lot of usage of ArrayList within Microsoft's code.
Related
For example, wouldn't this type:
https://msdn.microsoft.com/en-us/library/microsoft.xna.framework.vector2.aspx
... having public mutable fields like this:
https://msdn.microsoft.com/en-us/library/microsoft.xna.framework.vector2.x.aspx
... single-handedly make consuming F# code's immutability efforts kind of useless?
PS: performance must be preserved, no wrapping or dynamic instantiation of throw-away values.
PPS: I did some research and suspect the answer (negative) but would appreciate some input. It seems like a typical problem when not implementing everything in F# from scratch.
For collections of structs, this is not an issue. The collection remains immutable irrespective of the struct's members, since getting the struct from the collection returns a copy. Altering this copy does not alter the collection's contents.
Elsewhere, structs can be used to write wrappers without additional GC load. This requires to create methods for all features you want to keep and have them call the original methods. Unless the JIT doesn't inline the calls, this shouldn't cost performance. However, when wrapping reference types, this will create an empty default constructor on the wrapper type, resulting in a null reference if this constructor is called.
As a side note, I wouldn't recommend using vector classes from outside F#, since they are not unit-of-measure aware. In my experience, most vectors can be assigned physical units, which makes code safer and more readable.
You are correct, the short answer is no. However, at least in the case of the Vector2 class you show, many of the operations are implemented in an immutable fashion when you use the static versions of the methods. For example
var vecB = Vector2.Normalize(vecA);
is an immutable call. Unless the libraries you are using support some kind of immutability, you are stuck with having to implement the immutable functionality you want to have.
F# has a design goal of being a hybrid of mutable and immutable content so that it can access the rich functionality of .NET libraries when needed.
Lots of sources talks about this question but I dont understand the concept very well. IDictionary is generic, its type safety etc.
When I dig into EntityFrameworkv5 I see a property that is declared as below in the LogEntry class.
private IDictionary<string, object> extendedProperties;
The question is why they prefer IDictionary against Hashtable, hence Hashtable is also takes a key as a string and a object. Only the reason is making the property polymorphic by choosing IDictionary ?
Thanks in advance.
Nowadays, there are few reasons to use Hashtable. Dictionary<> is better than it in most respects. When it's not, you can usually find another strongly typed collection that serves your purpose even better than either.
Type-safe.
None of the severe overhead of boxing and unboxing.
Implements IDictionary<>, which is very compatible with .NET and 3rd party code.
Performs better than Hashtable in many areas. See links: Link #1, Link #2.
If you're asking why type a property as IDictionary<> instead of Dictionary<>, it's for several reasons.
It is generally considered best practice to use interfaces as often as possible, instead of regular types, especially in a framework.
It is possible to change the implementation of the interface fairly easily, but it's difficult to change the nature of a concrete class without causing compatibility problems with dependent code.
Using interfaces, you can take advantage of Covariance and Contravariance.
External code is more likely to consume the more general interface IDictionary<> than the concrete class Dictionary<>. Using IDictionary<> thus lets other developers to interact better with the property.
There are tons more, probably. These are just off the top of my head.
Well yes if they had defined extendedproperies as returning hashtable then they would have been stuck with that for all time, unless they wanted to break all the code that uses extended properties.
Whole point of the returning an Interface is it doesn't matter how the method is implemented as long as it keeps doing that.
"Only reason is making the property polymorphic" misses the point, there should be very few reasons why you shouldn't do this. If you can return an interface do return an interface, most of the time that's good design.
So most of the answers here are about comparing Dictionary to Hashtable for general purposes, not why they chose that particular implementation.
In that particular implementation, you are correct, it is using object as the return type, so the strongly typed benefits of dictionary are not available.
IMO it boils down to New vs Old, ArrayList, Hashtable etc are the older tech, and are largely disfavored in general, because they do not have a host of features (described in the other answers). Although those features are not used in this particular case, there are no strong benefits for switching back to the old tech, and it provides a better example for personal development.
So its more just a matter of "this is the way we do it now"
The HashTable is weakly typed and can only return Object. The Dictionary<> is strongly typed for whatever type you are storing in it.
Is it bad to use anonymous types in C#?
No, it is not. They are code generated classes at compiletime and perform as well as normal classes.
They're like other types, in terms of performance.
edit
To be more clear, I should have said that they perform exactly like other types because they are exactly like other types, except for the fact that the compiler generates the name. The only way performance would suffer is if you pass an instance of the anonymous type to another scope, where reflection or dynamic would have to be used just to access the properties. That would be expensive because it involves late binding to resolve everything at runtime.
Are anonymous types in themselves bad? No. If they were the C# team certainly wouldn't have wasted their time adding it to the language. Under the hood they just compile down to standard CLR types.
Can anonymous types, like practically every other language feature, be abused to the point of being non-performant. Sure.
An anonymous type in C# is still a static type and accessing its methods and properties is resolved by the compiler. The performance is comparable to explicit types.
It's not bad, sometimes it is convinient. For example, when using Linq, instead of creating a class that will be used only once, it's preferable to use anonymous types.
I need a generic collection class which I can add to, and enumerate over. Since ICollection<T> inherits from IEnumerable<T>, the class really just needs to inherit from ICollection<T>. Is there a simple generic class in the BCL that just inherits ICollection<T> like a generic version of CollectionBase? If not, then what class comes closest?
I would guess List<T> which is what I've been using but i don't need to sequential aspect. Is there anything better (by which I mean [smaller memory footprint/faster access/simpler])? Bag would be perfect if it existed.
EDIT 1: In my particular instance, I'm .concating to another IEnumerable, querying it, and then displaying the results (in no particular order). I'm not attempting to make my own class. I've just needed to make a throwaway collection so many times, that I thought it would be useful to find the best throwaway to use. Because I feel I've done something similar so many times, I felt I should keep this question as generic as possible (no pun intended), I know better now.
EDIT 2: Thanks for everybody's answers, As #BlueRaja pointed out, any simple class is going to have about the same overhead, and thus I think I will be sticking with my original ways of using List<T>. Since they are all about the same, my silly reasons of "It's easier to type", and "I don't have to bring in yet another using" aren't such bad reasons.
[smaller memory footprint/faster access/simpler]
They are all going to have pretty much the same memory footprint, and if you use ICollection the interface will not change.
What really matters is which will scale best for the operations you need: Linked-list does better appending/removal (of head/tail elements), while an array-based list has random-access. There are other structures too - which you should use depends on your application.
You'll probably want to look into Collection<T>. It was designed for the express purpose of subclassing, as the documentation indicates:
Provides the base class for a generic collection.
Having said that, any of the collections are fine; I've inherited from List<T>, Stack<T> and so on; pick whichever one is closest to the functionality you actually need.
Smaller and faster all depends on what exactly you're doing and what your needs are. The only other class I might recommend is LinkedList<> which implements ICollection<>.
You could use Reflector to check the .NET FCL and see what classes use that collection. (There is a search feature that can be started by F3.)
You can also take a look at the C5 Library to see if a collection has already been implemented that meets your needs. Check out page 13 of the C5 Manual for the collection interface hierarchy.
CollectionBase existed primarily to provide a simple mechanism to create typed collections. With Generics, all collections are now typed. The vast majority of cases where extensions of CollectionBase used to be used should now be using any of the built-in collections such as List<> or LinkedList<>.
Collection<> still exists for those that need to provide a custom collection for reasons other than type (i.e., extra validation on add, or some non-standard logic). Collection<> is not nearly as commonly used as CollectionBase was and serves a much smaller need.
The advantage of using generics is that it increases the type safety - you can only put in the correct type of thing, and you get out the correct type without requiring a cast. The only reason I can think of for not using generic collections is that you need to store some arbitrary data. Am I missing something? What other reasons are there to not use generics when dealing with collections?
If you need to store arbitrary data, use List<object> (or whatever). Then it's absolutely clear that it's deliberately arbitrary.
Other than that, I wouldn't use the non-generic collections for anything. I have used IEnumerable and IList when I've been converting an object reference and didn't know the type to cast it to at compile-time - so non-generic interfaces are useful sometimes... but not the non-generic classes themselves.
The obvious other reason is working with code (possibly legacy) that does not use generic collections.
You can see this happening in .NET itself. System.Windows.Form.Control.Controls is not generic, nor is System.Web.UI.Control.Controls.
Generics are almost always the right thing to use. Note that languages like Haskell and ML essentially only allow that model: there is no default "object" or "void*" in those languages at all.
The only reasons I might not use generics are:
When the appropriate type is simply not known at compile time. Things like deserializing objects, or instantiating objects through reflection.
When the users that will be using my code aren't familiar with them (yet). Not all engineers are comfortable using them, especially in some more advanced patterns like the CRTP.
The main advantage is the is no boxing or unboxing penalty with generic collections of value types. This can be seen if you examine the il using ildasm.exe. The generic containers give better performance for value types and a smaller performance improvement for reference types.
Type variance with generics can trip you up, but mostly you should use generic collections. There isn't a really a good reason to avoid them, and all the reason in the world to avoid un-typed collections like ArrayList.
Here's one answer: The change from Hashtable to Dictionary.
One thing I think you need to consider is that a generic collection is not always a drop in replacement for a non-generic collection. For example, Dictionary<object,object> can not simply be plugged in for an instance of Hashtable. They have very different behavior in a number of scenarios that can and will break programs. Switching between these two collections forces a good programmer to examine the use cases to ensure the differences do not bite them.
The non-generic Collection in the Microsoft.VisualBasic namespace has some annoying quirks and goofiness, and is in a lot of ways pretty horrible, but it also has a unique feature: it is the only collection which exhibits sensible semantics if it's modified during an enumeration; code which does something like delete all members of a Collection which meet a certain predicate may need to be significantly rewritten if some other collection type is used.