Well, I said I would have some comments for you when you woke up. Then I got involved in this Cooke paper, and all of a sudden it's almost 6am and I have a test in 5 hours. So my comments are gonna be brief for now.
- Socket subclasses - create two smaller subclasses of Socket, ListenSocket and ConnectSocket, to handle the functionality for incoming and outgoing sockets, respectively. (if you're wondering about the names, take a look at any classic BSD sockets implementation) This makes all of the individual Socket files a bit easier to read through, as the read/write functionality is common to all sockets, but a listening socket can't connect, and a connecting socket can't listen.
Generally, I like the idea. We can move forward on this for now, and see where it takes us, reserving the right to backtrack sometime down the line.
- Move some functionality to the constructor - open() should only need to be called once during the lifetime of a socket, and it must be called before anything else can be done, so I think it makes sense to put that into the constructor. Similarly, either listen() or connect() must be called on a socket before anything except open(), so it would make sense to put those in the constructors of their respective socket types. (or, if we don't split Socket into subclasses, simply have convenience constructors that take care of the listen/connect functionality.)
Again, generally like the idea. Again, we'll start moving on this path, and see what happens. I'll definitely know more when I start back in on the code later this week (after things have died down a bit school-wise).
- Move statistics functionality out of Socket - Statistics are nice, but I don't think their functionality logically belongs inside Socket... it may make more sense to move it to its own Statistics class that all Sockets register with, and they don't record statistics unless there is an attached Statistics object. (see my comments on the wiki for more thoughts)
Personally, I'd just as soon keep the stats within the Socket class. I don't see a reason for moving them to another class that the Socket then has to register itself with. As far as the performance gain (no stats are recorded unless the Socket is registered with the a Stats object), we can implement that a bit more simply as a flag (and perhaps using some magic make it perform just as well; dunno yet). To me, though, the stats are something that the Socket knows about itself, so it makes sense to have it within the Socket class. This is something I'd like to hear a more detailed argument for.
At any rate, I'm gonna call it a night. Cy'all tomorrow!
