On 28 Mar 2005, at 16:58, David Corbin wrote:

> On Monday 28 March 2005 11:11 am, Yohanes Santoso wrote:
>> David Corbin <dcorbin / machturtle.com> writes:
>>> Exactly my point.  So why does it inherit from TCPSocket, and more
>>> importanly IO? read, write and all the variations are all not 
>>> applicable,
>>> as far as I can tell.
>>>
>>> On Sunday 27 March 2005 08:15 pm, Eric Hodel wrote:
>>>> A TCP Server is just a socket you called listen(2) on:
>>
>> Exactly because it is a TCPSocket. A TCPServer is a TCPSocket with
>> bound local address(es) (whether it is a specific local address or all
>> addresses the local host responds to) and thus can be made to listen
>> to incoming TCP connections on those _bound_ local address(es).
>
> Is it really a TCPSocket, or is it just a TCP socket.  If it's a 
> TCPSocket, I
> could do this.
>
> socket = TCPServer('www.google.com', 80)
> socket.puts "GET /"

Would that make sense for the UNIX implementation of sockets?  No.

You'll probably get an ENOTCONN back because you haven't connected your 
socket to anything.

> etc.  It's not that I think I can't do that (it might actually work 
> for all I
> know), but I can't imagine why I would to.

Then why do you care?

Like a Socket you can call:

#addr, #getsockopt, #setsockopt, #shutdown

You can also IO::select a server socket.

Like an IO you can call:

#fcntl, #close, #close_read, #close_write, #closed?, #fileno

I think that's more than enough reason to make it a subclass of 
TCPSocket, rather than try to break the shared functionality of regular 
sockets and server sockets (and IOs) into common code only to recombine 
them again.

I'd rather use some handwavium and subclass.  Sounds far more 
convenient.

-- 
Eric Hodel - drbrain / segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04