Re: [Boost-users] Library Interface Design

David Abrahams wrote:

Edward Diener writes:

...

Most .Net objects aren't half-baked objects to use, but they are objects which are created with a default constructor, which gives people the idea that they are not ready to use. They rely quite a bit on properties being set in order to use, and those properties are set via the design-time interface in Visual Studio, which then injects code in the default constructor to set the properties. So while it looks like these objects are not ready to use, they really are.

Edward, I know little of .Net, so I'd appreciate it if you could help me out here. When you say "design-time interface," what are you talking about? Some kind of GUI?

Yes. The Visual Studio designer allows one to drop components into other components and forms, and modifies the source code constructors which create the component and/or form. A component is also a component container, allowing other components to be nested inside it, and a form is the equivalent of a Windows window which naturally can have components in it. A component is a particular kind of class and controls, which people are used to seeing in forms ( windows ), are just visual components.

Are you saying that this GUI modifies the compiled binary, leaving no textual trace of member initialization values in the original source for the class?

The original source. The Visual Studio designer is actually modifying the constructors to setup the components in the source code and then this gets compiled into the resulting binary. The areas being modified are marked off in the source so that the user does not change them but allows the Visual Studio designer do it instead. The actual way it does this is better than it sounds. When you first create a component and/or form from menus in Visual Studio, the constructors get an InitializeComponents(); call added to them with the appropriate definition later in the source code. It is in this InitializeComponents() definition that the Visual Studio Designer manipulates code based on the properties and events of components added to a component and/or a form. There are two constructors, a default one which takes no parameters and an other one which is passed a container and in which codes gets added automatically which adds the component to the container.

[for what it's worth, I don't think the answers to this question can affect my stance on Scott's question at all. Either the objects are fully-baked, or not, upon construction. How they come to be baked, and whether this "design-time interface" thing is a good idea, are separate issues]

I agree with your analysis. I was only trying to point out that the default constructor ( or container constructor ) of .Net was erroneously causing others, including the OP, to think that .Net creates classes which are not ready to be used upon construction. They are, by and large, ready to use immediately because the necessary code to setup their properties and events has already been injected into the constructors when the programmer manipulated a form or a component in the visual designer. So having someone point out to the OP that .Net is an example of an environment in which two-phase construction is the rule is just plain wrong, and any inference about software design of classes following this idiom should not be made from that erroneous conclusion.