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)