[Swan-dev] the coding twine holding end's .host_addr, .client, .port, .protocol and .has_client together

[D. Hugh Redelmeier]

| From: Andrew Cagney <andrew.cagney at gmail.com>

| - instantiate non-template connections (this idea keeps coming up on IRC)

This is off the top of my head.  It might be wrong.  And too
philosophical.

The original idea was that connections were immutable -- all changes
were in state objects.

It was convenient to add mutable fields to keep track of the states
using connections.  Arguably that should have been in another
datastructure, but it was convenient to jam it in there because there
was a one-to-one relationship with this datastructure and a
connection.  For example: keeping track of the most recent state
that was associated with the connection.

(State objects are not one-to-one with connections.  That's why it was
obvious that they should be separate datastructures.  But an
alternative would be to copy all of the connection object into the
state; that copy could be mutated.)

Then connections were derived from other ones, with more details
filled in.  This was instantiation.  It could happen for a variety of
reasons and with a variety of details added.

If the new thing has a one-to-one relationship with the connection,
there was a strong temptation to just jam the additional info into a
connection.  This may or may not be a mistake.  I think that's what
you are dealing with.

I do think that it is wrong to lose something that came from a config
file.