FWIW, I think this isn't a good idea, because it leads to increased coupling.
While you could argue that it would only make sense, since C# already has the 'where T : new()' constraint, I would rather argue that the 'new()' constraint never should have been added in the first place. However, now it's too late to remove it, but there's no reason to make things worse.
For more details, see the section about the Constrained Construction anti-pattern in my book: http://amzn.to/12p90MG
39 votesunder review · 3 comments · Visual Studio IDE » Languages - F# Tools · Flag idea as inappropriate… · Admin →
Dear F# product team. This suggestion was reported more than two years ago, and has seen no activity since then.
Currently, it's taking up people's votes. Could you please either accept or decline it, so that we can all move along?Mark Seemann supported this idea ·
Thank you all for voting on this suggestion. The team has heard you and is considering this request, possibly for a future release.
Deonhe – MSFT .NET Framework team
Oh, and regarding the Dependency Injection (DI) options: .NET has had DI support since 1.0. It's called "interfaces".
Learn DI instead of clamouring for a tool you don't understand how to use.
This is, IMO, not a good suggestion. Not because it's Enterprise Library (of which I have no particular opinion), but because the BCL is already too big.
We already have NuGet as a fine delivery mechanism for optional frameworks, and if you can't already pull Enterprise Library from there, it would be easy to make it available via that channel.
Besides, putting Enterprise Library into the BCL (or VS) would lock it to the release cycle of that parent product. Look at the ASP.NET framework, that did exactly the opposite (pulled out of the BCL) to be able to iterate faster.
515 votesMark Seemann shared this idea ·