On Sat, Jan 28, 2012 at 06:37:04AM -0600, Graham Barr wrote: > If it is truly a drop in replacement, why is it a separate module ? > Why not make the changes to ::INET Primarily, because it breaks some assumptions that user code may have about the sorts of sockets it creates. Specifically, the following invariants are true if $class eq "IO::Socket::INET". $class->new(...)->sockdomain == PF_INET sockaddr_family($class->new(...)->sockname) == AF_INET sockaddr_family($class->new(...)->peername) == AF_INET unpack_sockaddr_in($class->new(...)->sockname) doesn't die unpack_sockaddr_in($class->new(...)->peername) doesn't die These invariants are no longer true if IO::Socket::INET were able to construct PF_INET6 sockets bound or connected to AF_INET6 addresses. This was why I decided to make a ::IP subclass instead. Provided that applications don't make the above assumptions, then the fact that the API is otherwise a dropin replacement means they can simply s/::INET/::IP/ over their source code. I've also discussed this at length on p5p@; see for example the thread at: http://code.activestate.com/lists/perl5-porters/169176/ and my blog post at: http://leonerds-code.blogspot.com/2010/09/module-name-suggestions-proper-iosocket.html -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/Thread Previous | Thread Next