Re: [Boost-users] Library Interface Design

From: Edward Diener (eldiener_at_[hidden])
Date: 2006-09-20 13:55:31

David Abrahams wrote:
> Edward Diener <eldiener_at_[hidden]> 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.