+972 52-548-6969
Why I hate internals, yet again
time to read 1 min | 118 words
So here I am searching for an implementation of a WeakHashtable, and imagine my surprise when I find out that the BCL already has one such implementation. Imagine my lack of surprise to find that System.ComponentModel.WeakHashtable is internal, thus rendering it near useless to me.So annoying, frustrating and irritating.
Update:
Oh, and as if it is not enough, it appears that there are two implementation of WeakHashtable in the BCL. In two different assemblies (System and System.Windows.Forms).
From browsing the code, it looks like they just copy/paste the code, instead, you know, recognizing that this is an actual need and exposing this.
Comments
These are probably just development guidelines:
Refactoring is only permitted from 3 occurrences of the same code
What happens in the BCL, stays in the BCL
If you're looking for a good implementation. Here's where I got the code I am using in Caliburn:
http://blogs.msdn.com/nicholg/archive/2006/06/04/617466.aspx
Ooooh... are we going to start listing all the sins in the BCL? I could probably dump a dozen or so crimes off the top of my head :) This could be a new meme
I am going to post each and every internal class that I encounter that I want to use.
Feel free to do the same, in fact, please do the same, I want to get the pain across to the people who write the framework.
it seems the intenals most of the time indicate something they didn't have time to make good enough for the public but still needed to use. it either have implications or has an api that is likely to change
What's up Ayende.
This is just a "hunch" but I bet the reason these were just copied from one to the other is there were different teams writing the two different namespaces. And then getting this into the correct namespace would involve another team. In the end, it was easier to copy. It is probably a case of:
"It is easier to leave the Silo up than make the concerted effort to tear it down."
I also encourage others to let this stuff be known. The MVP Summit is right around the corner and there will be a lot of us that will have direct access to the product teams to discuss these very issues and provide this feedback.
It's my belief that "internal" keyword should be removed from the .net spec. The only time and reason when one would use it is when unable to properly design your classes... and seeing how much it's abused in the BCL, it's pretty daunting...
Internal also means no need to write documentation.
It's my belief that "internal" keyword should be removed from the .net spec. The only time and reason when one would use it is when unable to properly design your classes... and seeing how much it's abused in the BCL, it's pretty daunting...
Internal also means no need to write documentation.
I'm finding "internal" to be very useful with regards to my data provider. I can expose only what I want to the public and still have everything else available to the rest in the assembly.
That said, I agree that having most of the BCL "internal" (and sealed!) makes life somewhat difficult.
I would argue that it isn't "in the BCL", but part of private implementation details. MS provides and supports an implementation of the BCL. MS has committed to it, and built an organization it knows can and will support it to great lengths. That’s one of the top reasons companies invest heavily in MS technologies.
If MS was to open up access to these implementation details, they would also have to be supported, and it would make change management much more difficult. You could argue against it, and say “no, MS could declare these classes ‘internal and volatile’, and people would know they might need to change code using it during upgrades". In reality, though, that would never work.
Developers and many of those highly skilled architects would start using these classes everywhere in their code. Every time an upgrade then breaks some application, perhaps in a subtle way (such as changing the underlying algorithm), MS would face a high risk of getting blamed. Perhaps not blamed openly in the media, but often internally by irresponsible developers. “Management: Why did the app break? Developer: Microsoft’s platform is hopelessly bug-ridden, it always breaks our app.”
I think MS is much better off keeping those classes internal. Sure, some grumpy old fogies will complain about it, but it’s nothing compared to the alternative.
C-J,
"Sure, some grumpy old fogies will complain about it, but it’s nothing compared to the alternative."
Which alternative? Just making the classes public or also actually making the classes fit to be public?
/Mats
The alternative being "making all internal classes public". Doing so would require huge investments in more thorough design and code reviews, and producing documentation (in several languages), and what not. It would be really expensive, and it would take a lot of time (and I guess time is the most limiting factor in Microsoft's case).
Before complaining too much about the number of internals I'd need to see the churn rate they've been through from bits to bits.
If they're being re-factored like mad for performance or if they're changing args to accommodate new functionality then I say more power too em. To the outside world an internal can be irritating, but from the development teams' point of view anything public is either a etched in stone or a breaking change waiting to happen.
Comment preview