2009/10/30 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig,
Exposing the streams is an interesting idea, and I think I could adapt it should I ever want to back-port what I am doing to Dolphin (something I want to keep open to allow an incremental escape from Windows). Â That might be the answer.
Subclassing socket to add stream protocol is a very bad idea IMHO - there is too much overuse of inheritance in Squeak, and that would only add to it.
Right, it is BAD idea. I just illustrated the idea of keeping 1:1 correspondence between socket and stream at the extremum :)
Re UDP sockets, I could ask similar questions about the current mix of client and server behavior in Socket.
what exactly you mean by server behavior? For what i see in Socket, its a wrapping aroung BSD-socket functionality, so you can send #accept using wrong socket as well as in C you can call accept() function and get similar results. Making a Socket interface behave similar to original sockets library, despite how bad or good the original design, having own reasons, which not even worth mentioning. So, i prefer to leave Socket to resemble the original BSD sockets functionality & behavior as close as possible, and if one wants a custom behavior, he can always create a subclass, or wrap it with own object, such as stream or whatever..
Thanks!
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 30, 2009 3:54 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket>>socketStream
2009/10/30 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Hello all,
What would be involved in adding a socket stream instance variable/accessor to Socket? Â Is that something you would support? Â So far, I created a shared dictionary (cleared on true startup) of sockets to streams, so once created, the stream is associated with the corresponding socket, and accessible from same using #socketStream. Â From there, I have #readStream and #writeStream accessors, which return the one stream - Dolphin separates them, and there is no reason to break the news to my code just yet.
Err... what kind of stream you would answer for UDP socket, a socket which inherently doesn't mean to support streaming capabilities? The only reason why i would need to enforce 1:1 association of stream-based socket with corresponding stream is to make sure that nobody constructs multiple streams for using the same socket and in this way abuses it. But i wouldn't care about that. There are numerous ways how to shoot in own foot, and given case is very unlikely happen, unless you doing a really stupid things, like exposing the sockets to different layers of your application instead of exposing the streams which they should use.
But from this perspective, wouldn't it be better to simply create a subclass of Socket, which supports a stream protocol, so you enforcing the 1:1 rule from very start and there is no way how to create one socket to many streams association.
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.