On 6 août 2011, at 00:56, Igor Stasenko wrote: > From user's POV, socket should support certain protocol. Period. > Nobody interesting where it comes from, who creating it and where
Exactly, this is why we will have constructor methods. So, creating a socket will be simply as : OCNConversationSocket new OCNConversationSocket connectedTo: 'someserverNameOrIP' port: portNumber But, we didn't implement these yet. > A server socket has to provide only few things to users (after it > bound and started listening): > - accept new connection > - close > > The rest of socket protocol is useless and will produce the errors if > you use it. > >> Users of Ocean are not supposed to subclass these classes. >> If you want to implement a protocol, you need to go through a decorator >> pattern or a similar solution. >> > Yes, and i am asking, why these two subclasses are not decorators themselves? > Because they are using only a subset of socket's functionality (you > cannot connect once you already connected, > you cannot send or receive data using socket which listening connections etc). > Yes. There is a lifecycle. We are aware of this problem. We write extensive tests for it. There are explicit exceptions to signal missuses, instead of a doesNotUnderstand. Anyway, we definetely have to pair-program a bit. Let's do it during the camp preceeding the ESUG conf. Noury http://car.mines-douai.fr/noury -- -19èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMA’11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France -5th International Conference on Smalltalk Technologies http://www.fast.org.ar November 3th - 5th, 2011 Universidad Nacional de Quilmes (Argentina)
