2009/10/30 Schwab,Wilhelm K <[email protected]>: > 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: [email protected] > [mailto:[email protected]] On Behalf Of Igor > Stasenko > Sent: Friday, October 30, 2009 3:54 PM > To: [email protected] > Subject: Re: [Pharo-project] Socket>>socketStream > > 2009/10/30 Schwab,Wilhelm K <[email protected]>: >> 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 >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
