On Monday, 10 April 2017 at 16:18:20 UTC, Jonathan Marler wrote:
An interesting benefit. However, I don't think this is the
ideal way to support such a use case.
If I was doing it myself, I'd probably do an interface / final
class split too (which also opens up a wee bit of additional easy
optimization), but the Socket class isn't *bad* for this.
My first thought is that since the interface you are using (the
Socket class) wasn't really designed to be overridden, you
probably had to do some interesting hacks to make it work.
No, the code is very straight-forward, regular class method
overrides with appropriate forwards to the base class
implementation where needed.
For example, when you accept a new socket, you probably had to
delete the Socket object you got and create a new SSLSocket
object passing the handle from one to the other, and make sure
I didn't implement the server, but if I did, it would be another
simple case of
override SslSocket accept() {
return new SslSocket(....);
}
or better yet, `override SslSocket accepting() { ...}`, since
there IS a method specifically designed for this:
http://dpldocs.info/experimental-docs/std.socket.Socket.accepting.html
That'd work fine too.
