On Monday, 10 April 2017 at 18:57:13 UTC, Adam D. Ruppe wrote:
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.
Yeah I agree, not perfect but not *bad*.
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.
Ah, it seems someone already ran into this accept problem, hence
why the new "accepting" function was added. Funny timing that
this was added near the time I asked the question.
Since my last post I've been looking through std.socket and I see
quite a bit of inefficiency especially when it comes to GC
memory. I think moving forward the best solution for me is to
use my version of std.socket. It would also be great if Walter's
new ref-counted exceptions proposal gets implemented soon because
then I could make it @nogc. Anyway, thanks for the feedback.
