I can understand at first glance we may perceive ListenAndServeTLS as a convenience helper, but if enough people to copy and paste its contents to modify it, then the sublety is the function is actually assumed to be part of a Foundation/Framework that people build on top of. It is under the golang/net after all. It was meant simply to be used and extended, NOT rewritten.
A framework usually has a manner in which to access all its class/duck-type's attributes and services. In this case the package net has a number of duck-types, Client, Server. Most of the Server's attributes are accessible, but stunningly the listener itself does not belong to the Server duck-type when I believe it should. Otherwise the other suggestion would be to make it available by making it a return variable if other framework devs feel it shouldn't be part of the Server duck-type. For those that don't want to tweak the listener, they can simply use the _ standard to ignore that return variable. That said, I believe the listener is core and should be available from this one service. I'm sure there are other developers that rely on ListenAndServeTLS and implicit understand exactly what it does. I'm not asking to change anything in their understanding about its behaviour. I asking the golang team to change something to in its characteristics which fundamentally belongs to the Server duck-type which extends its original meaning to something developers assume to be there in the first place. I'm surprised LimitListener(srv.tlsListener, connectionCount) is not part of the Server duck-type's api. It makes sense to be there. I'm stunned it's not there. That's why I came to the forum to ask why it wasn't there the first place. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
