Rationale on the System.Collections.ObjectModel namespace
I'm curious to know the rationale on having the System.Collections.ObjectModel namespace. More importantly I'm curious to know why only 3 generic collection classes are in there while the interfaces and the remaining generic classes (Dictionary, List, etc.) are in System.Collections.Generic. It seems to me that this is counterintuitive. I thought the original purpose of System.Collections.Generic was to isolate generic collections from regular collections. If so then it would seem that System.Collections.ObjectModel should be for non-generic collections.
Additionally it would seem to me that the hierarchy violates some of the core rules of the class library design (as given in
Design Guidelines for Class Library Developers from Microsoft. The first guideline violated is the fact that the namespace has only 3 classes. At a minimal I would have expected the generic collection implementation classes (Dictionary, List, etc.) to be moved there as well. The second guideline it breaks is that a nested namespace should be a specialization of its parent. In this case I would expect that since the classes implement generic interfaces the namespace should be System.Collections.Generic.ObjectModel. Finally I have a problem with the name ObjectModel. To me an object model is a model of the logical objects in a system. By definition the .NET library doesn't really have an object model for collections. It simply provides the interfaces and default implementations.
Is there anybody that can clarify why this decision was made? I saw a bug written up about it but Microsoft said it was by design because it made more sense but I don't agree. I know have to remember that if I need to implement the interface I need to go to System.Collections.Generic but if I want to use the default implementation I need to go to System.Collections.ObjectModel. Furthermore if I want the non-generic implementation I have to go to System.Collections. Oh, and because I want my collections to play nice with the designer I also need to include System.ComponentModel. This is even more confusing because I believe the original Microsoft reply actually said System.Collections.ComponentModel which isn't right in B2.
Thanks,
Michael Taylor - 7/26/05
Actually, the rationale is really unconvincing (basically: we did it because VB programmers are incompetent). In other hand, I found many of the user comments very convicing (especially the comparison with Java).
Frankly, the distinction between
System.Collections.Generics and
System.Collections.ObjectModel is just confusing. It's does not even stand against basic FxCop rule (i.e. don't do a namespace with 3 elements inside like
ObjectModel).
I trully expect improvements in this direction altough I know it's late for .Net 2.0.
Joannes
Joannes... As a VB .NET developer who was in the process of researching this very subject today, I gotta say that your response about how incompetent I am for being a VB programmer solved my problem. Through your help, I now realize that instead of wasting my time trying to learn about the ObjectModel & Generics namespaces to improve my knowledge, I should throw away all that money I am earning and the career path I chose in the Visual Basic Application Development industry instead...
Out of curiosity, it's been 5+ months since you posted your biased opinions here... Are you still confused about this? If you still are (which I assume since you haven't provided a solution or workaround yet), then I'll make you a promise... When I found the solution to this, I'll help out not only you but anybody else that might be interested...
You know what... I'm really not trying to be an idiot here. Looking at all of your posts on these forums asking for help, I just hope you don't get a response similar to yours here.
There is maybe some misunderstanding, I haven't said that
VB programmers ignore X and Y, my position was the opposite,
don't assume that VB programmers ... .
To answer your question, I am not confused any more by the ObjectModel, I have just learned to live without paying attention to this namespace 
.
I am still considering that the ObjectModel namespace is a poor solution to whatever problem it is supposed to solve (although Generics are great). IMO, this namespace costs roughly one hour of reflexion each new .Net developper to figure out why it is there. Pill up 100 poor decisions across .Net and a new developper spends roughly 2 weeks just to figure out things that are definitively worth to be ignored.
Joannes
First, my apologies to you... I hate it when people get emotional with a part of a statement instead of the whole, but I HATE it even MORE when I do it myself!
As such, though, you must admit what you actually did say could easily have been taken out of context (to prove my point, I DID! 
) and I feel, just like you might, that it could have probably been worded differently. You use VB only for negative purposes while using Java, the C# derivative, for the positive. It's hard to believe that the only thought process was with VB developers in mind. I could easily say that the rationale to included automatic commenting in C# and not VB in VS.NET 2003 was unconvincing (basically: we did it because C# programmers are incompetent in commenting code), but it's not the point. What the VB community did was create VBCommenter and complained to MS, and lo and behold, it's not included in VB .NET 2005.
NOW... regarding Generics and the namespace... you are 100% correct in that System.Collections.Generics IS confusing. Hence my search for an answer on this subject!
To sum up, I apologize if I was off-base, but hopefully you can understand why I was thinking irrationally when I read it and posted my response! :)
