C#

Form that was specified to be the MdiParent for this form is not an MdiContainer.<br />
Parameter name: value.

<br />
"The Smalltalk solution. Smalltalk (and Java, following its<br />
example) took a simple and straightforward approach: You want to<br />
reuse code, so use inheritance. To implement this, each container<br />
class holds items of the generic base class Object (similar to the<br />
example at the end of Chapter 15). But because the library in<br />
Smalltalk is of such fundamental importance, you don’t ever create<br />
a class from scratch. Instead, you must always inherit it from an<br />
existing class. You find a class as close as possible to the one you<br />
want, inherit from it, and make a few changes. Obviously, this is a<br />
benefit because it minimizes your effort (and explains why you<br />
spend a lot of time learning the class library before becoming an<br />
effective Smalltalk programmer).<br />
But it also means that all classes in Smalltalk end up being part of a<br />
single inheritance tree. You must inherit from a branch of this tree<br />
when creating a new class. Most of the tree is already there (it’s the<br />
Smalltalk class library), and at the root of the tree is a class called<br />
Object – the same class that each Smalltalk container holds.<br />
This is a neat trick because it means that every class in the<br />
Smalltalk (and Java1) class hierarchy is derived from Object, so<br />
every class can be held in every container (including that container<br />
itself). This type of single-tree hierarchy based on a fundamental<br />
generic type (often named Object, which is also the case in Java) is<br />
referred to as an "object-based hierarchy." You may have heard this<br />
term and assumed it was some new fundamental concept in OOP,<br />
like polymorphism. It simply refers to a class hierarchy with Object<br />
(or some similar name) at its root and container classes that hold<br />
Object.<br />
Because the Smalltalk class library had a much longer history and<br />
experience behind it than did C++, and because the original C++<br />
compilers had no container class libraries, it seemed like a good<br />
idea to duplicate the Smalltalk library in C++. This was done as an<br />
experiment with an early C++ implementation2, and because it<br />
1 With the exception, in Java, of the primitive data types. These were made non-<br />
Objects for efficiency.<br />
2 The OOPS library, by Keith Gorlen while he was at NIH.<br />
16: Introduction to Templates 695<br />
represented a significant body of code, many people began using it.<br />
In the process of trying to use the container classes, they discovered<br />
a problem.<br />
The problem was that in Smalltalk (and most other OOP languages<br />
that I know of), all classes are automatically derived from a single<br />
hierarchy, but this isn’t true in C++. You might have your nice<br />
object-based hierarchy with its container classes, but then you<br />
might buy a set of shape classes or aircraft classes from another<br />
vendor who didn’t use that hierarchy. (For one thing, using that<br />
hierarchy imposes overhead, which C programmers eschew.) How<br />
do you insert a separate class tree into the container class in your<br />
object-based hierarchy? Here’s what the problem looks like:"<br />
<br />
And a diagram<br />
and he writes:<br />
<br />
"Because C++ supports multiple independent hierarchies,<br />
Smalltalk’s object-based hierarchy does not work so well."<br />