What I am hoping to do is make a constructor for a derived class that
can accept an instance of the base class. Maybe this just is not possible?
I am working with the new SSLStream in the 2005 beta. They came up with
what seems to be an awkward object model to me. The SSLStream has nearly
the same member signature as a NetworkStream. Both are derived from
Stream. But in both cases you need a TCPClient instance to get them
going. This leaves you constantly checking to see if the socket has been
negotiated for SSL, and if it has you must do I/O on the SSLStream and
if not on the "Client" property of the TCPClient.
Other implementors have chosen to give you a single socket type object
that can be used for either clear text or SSL encrypted communications.
This is MUCH handier. For .NET I sure wish they would have made
TCPClient upgradable, and as such the Client property would give you an
upgraded NetworkStream. I am creating software that has to be able to
upgrade and downgrade the socket on the fly.
My thought was to derive a class from TCPClient with a property called
"NetStream" that would either return the client property of TCPClient if
SSL has not yet been negotiated, or the SSLStream object if it has, but
in both cases cast as a Stream. The complication is that when listening
for connections the framework instances the TCPClient for you in your
call to Accept, so you already have the instance for the base for this
new derived class. What would be cool is if there were a way to make an
overloaded constructor in my derived class that would accept the
instance of the base class.
I know there are some new object capabilities in 2005, but haven't found
a way to do this.
Can you teach an old dog a new trick?