From: "Mauricio Fernández" Date: 2003-05-20T01:21:50+09:00 Subject: Re: State Pattern Implementation On Tue, May 20, 2003 at 01:04:34AM +0900, Robert Klemme wrote: > > You mean this? > > > > class Client > > def initialize > > @state = InitialState.new > > end > > > > def method_missing(meth, *args, &block) > > @state = @state.send(meth, *args, &block) > > nil # dummy > > end > > end > > Yes. > > > that implies that the methods cannot return useful values, they have to > > give the next method. > > Is it reasonable to have a state transition method return anything other > than the new state? You could put state dependent instance vars into the > state instance. Hmmm... Not satisfying, too. As I see it, you simply use an object which goes through internal transformations (state) depending on the operations you perform and whatever else. Why should the client get the internal state? It should be hidden inside the object. For instance (kinda like the example in the GOF, but cannot really remember) socket = TCPConnection.new("www.somehost.com", 80) socket.state # => "offline" data = socket.receive(100) # on demand connection socket.state # => "connected" ... > > Yeah, but what bugs me about these is the need for a reference back from > the state to the client. Isn't there another way to solve this? I mean, > putting additional state into the state classes might require handing this > state through to the next state instance. Gee, I guess I'll have to buy > that DP book... > > > Wish I had my DP.book_instance at hand too ;-) My case is worse because I bought it but then left it 1800km away :-P -- _ _ | |__ __ _| |_ ___ _ __ ___ __ _ _ __ | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \ | |_) | (_| | |_\__ \ | | | | | (_| | | | | |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_| Running Debian GNU/Linux Sid (unstable) batsman dot geo at yahoo dot com ECRC hat keine lynx komp. seiten, sowas MUSS ja pleite gehen ;-)= -- Getty on #LinuxGER