Sto leggendo il bellissimo libro di Dino & Andrea, "Microsoft .NET: Architecting Applications for the Enterprise" e mi ha incuriosito questa loro osservazione alla pagina 362: "[...] Microsoft Foundation Classes (MFC) offered more than a decade ago an architecture with some points in common with MVC - particularly, the Document/View (DV) model. DV can be seen as a version of MVC where the view and controller are fused together. We really don't know whether the MFC team intentionally discarded MVC to embrace DV; our feeling, however, is that DV blossomed autonomously during the design by simply applying correctly and diffusely the SoC principle".

Sembra che alla PDC del 1995, un membro del team di MFC abbia raccontato proprio la storia del "MVC versus DV" nella scelta architetturale di MFC: "[...] for the controller’s message mapping mechanism, can’t we just reuse MFC’s message map solution? Ideally, yes. But there is one big problem here... A separate controller class for message handlers may sound like a good idea, but MFC was designed in such a way that this was thought impossible. MFC allows commands such as menu picks to be rerouted to non-windows, but not windows messages such as mouse clicks. In MFC, only a CWnd can receive windows messages and only one instance of a CWnd can receive the messages for a real Windows window. Since a controller is meant to be a non-window that can handle windows messages and exist in multiple instances per window, we seem to be stuck! An interesting aside, this problem was sited by an original MFC team member as the main reason Microsoft emulated MVC for the CDocument and CView, but stopped short of implementing a controller (MFC Professional Developers Conference, 1995)". Interessante...

The variable e is not visible to or accessible to the expression x or the embedded statement or any other source code of the program. The variable v is read-only in the embedded statement. If there is not an explicit conversion from T (the element type) to V (the type in the foreach statement), an error is produced and no further steps are taken."

The Combine method had an interesting ride in the standardization process. It was originally part of the Path class, then removed because it was thought to be too platform-specific, then added back because it was decided it was not any more platform-specific than any of the other methods in this class.

This is a good question. I was digging through the history of this file to see if I could figure out what happened, and it’s not clear. We’ve had this “hole” in the TypeCode enum since October of 2000, and I can’t find an older set of bits. But, I’m sure that comment in IConvertible is right – this used to be TimeSpan. For TimeSpan, it’s possible we thought it would be interesting for a while, then we realized that frankly not that many people need to convert a Decimal to a TimeSpan, then removed it.

You might ask why we didn’t “fix” the enum when we removed whichever of these values we had originally added. It turns out that whenever we have a breaking change internally, we need to recompile all the code that might possibly depend on the removed or changed public surface area. For us, that would mean rebuilding everything that might have referred to TypeCode.String, whose value would have changed from 18 to 17. While we do go through that process internally in DevDiv, it is costly & painful for us. Back then with some underdeveloped internal processes, it usually took 2 weeks, then even longer if your change requires a rebuilt compiler to be checked in as a new “safe” build of a compiler. Back in 2000, we were racing to ship as soon as possible (even though we didn’t ship for another year or two), so we wanted to limit churn like this. It’s sometimes easier to not deal with that level of churn in the product.

For your other question about IValue, that was the original name for IConvertible. We exposed a Variant type to match OLE Automation’s VARIANT type on the native side, for COM Interop reasons. The VB team actually was thinking that Variant should be conceptually the root of their object hierarchy (at least in terms of how types were exposed in VB 7), but that seemed a little silly. Fortunately, Anders Hejlsberg convinced them to use Object instead and we’d expose IConvertible on the base data types to allow VB users to easily change from one data type to another. So we marked Variant internal & we only use it in a handful of places internally for COM-related functionality.

// The IValue interface represents an object that contains a value. This
// interface is implemented by the following types in the System namespace:
// Boolean, Char, SByte, Byte, Int16, UInt16, Int32, UInt32, Int64, UInt64,
// Single, Double, Decimal, DateTime, TimeSpan, and String. The interface may
// be implemented by other types that are to be considered values.

// Note that when an object has a given TypeCode, there is no guarantee that
// the object is an instance of the corresponding System.XXX value class. For
// example, an object with the type code TypeCode.Int32 might actually be an
// instance of a nullable 32-bit integer type