<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 3 Apr 2017, at 5:33 PM, Gelareh Taban <<a href="mailto:gtaban@us.ibm.com" class="">gtaban@us.ibm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><p class=""><tt class=""><font size="2" class="">There are 2 hard problems in computer science: cache invalidation, </font></tt><tt class=""><font size="2" class="">**naming things</font></tt><tt class=""><font size="2" class="">**, and off-by-1 errors. -- Leon Bambrick</font></tt><br class=""><br class=""><tt class=""><font size="2" class="">:-) </font></tt><br class=""><br class=""><br class=""><tt class=""><font size="2" class="">> > * These are essentially delegate methods notifying the TLS engine of an event. </font></tt><br class=""><tt class=""><font size="2" class="">> > `onAccept` says that the system has accepted a connection and the TLS engine should </font></tt><br class=""><tt class=""><font size="2" class="">> > do what it needs to do with it, `onSend` means the system is about to send data and </font></tt><br class=""><tt class=""><font size="2" class="">> > it needs the TLS engine to modify it, etc. If so, Swift APIs more often use words like </font></tt><br class=""><tt class=""><font size="2" class="">> > `should`, `will`, or `did` than `on`, particularly since they're more precise about the </font></tt><br class=""><tt class=""><font size="2" class="">> > timing of the delegate method compared to the actual event.<br class="">> <br class="">> +1 onXXX methods look definitely non-Swifty to me.</font></tt><br class=""><br class=""><br class=""><tt class=""><font size="2" class="">Fair enough. What do you recommend?</font></tt><br class=""></p></div></div></blockquote>what about:</div><div><br class=""></div><div>onAccept -> didAccept</div><div>onDestroy -> didDestroy / wasDestroyed</div><div>onClientCreate -> clientWasCreated</div><div>onServerCreate -> serverWasCreated</div><div>…</div><div><br class=""></div><div>etc, you get the point.</div><div><blockquote type="cite" class=""><div class=""><div class=""><p class=""><tt class=""><font size="2" class="">I agree that Service is not a particularly good name but that was the best I could think of. I liked Engine but (1) we are not implementing anything, just overlaying and (2) I didnt want any confusion with with the SSL Engine of OpenSSL.</font></tt><br class=""><br class=""><tt class=""><font size="2" class="">So again, I would be interested in your recommendations!</font></tt><br class=""></p></div></div></blockquote><div>(1) `Service` has the same problem</div><div> if it’s just overlaying, maybe you should name it ‘TLSOverlay’, ‘TLSMiddleware’ or something.</div><div> I still think, `Engine` is a pretty good name though, but will keep thinking for better ones.</div></div><br class=""></body></html>