become: is slow scan all the memory then the methods using it is unreadable break potential static analysis keep real weapons for real evils no need to use a nuclear bomb for a fly if you can avoid it, avoid it. and for state pattern you can and the book (smalltalk design companion says the same).
Stef On May 2, 2011, at 3:36 PM, [email protected] wrote: > Thx, can you be more specific? I'm looking for reasons. > > Door>>open, close (delegating to state) > OpenedDoorState>>close > ClosedDoorState>>open > > delegation, empty methods, throwing exceptions, that all seems just ugly, > I don't want anybody looking in methods browser > to think that every door can be closed or opened, > because that's not right. > > maybe I don't want object to become another object, maybe I just want to > change its class? (is it possible?) > > I want empty Door class (or implementing only things possible with any door) > and subclasses representing their states. > > > > Dne Mon, 02 May 2011 14:19:31 +0200 Stéphane Ducasse > <[email protected]> napsal(a): > >> Do not use become: for state pattern. It is not worth. >> >> Stef >> >> On May 2, 2011, at 3:11 PM, [email protected] wrote: >> >>> I see that #become: is hard to follow in code (either for human or analysis >>> tools) >>> >>> I'm trying to express state-pattern: >>> >>> OpenedDoor>>close >>> ClosedDoor>>open >>> >>> And I would like to avoid this: >>> Door>>close >>> state close. >>> Door>>open >>> state open. >>> >>> Because if Door cannot be opened depending on its current state, IMHO no >>> method should be >>> there. Which is why become: seems as the best fit. >>> >>> >>> I would also like to know why proxy is considered better, because >>> #messageNotUnderstood >>> seems pretty magic too. (except the fact that become: can crash VM) >>> >>> >>> Dne Mon, 02 May 2011 14:39:40 +0200 Mariano Martinez Peck >>> <[email protected]> napsal(a): >>> >>>> 2011/5/2 [email protected] <[email protected]> >>>> >>>>> >>>>> I've heard that become: is considered to be magic >>>>> and should be avoided and replaced by either AOP or proxies, >>>>> >>>>> >>>> That's "normally" true. But it depends what are you doing. For a normal >>>> app, >>>> busieness, etc, it is not likely you will need a #become:. >>>> However, if you are doing low level stuff, frameworks or hacky things you >>>> may need it. >>>> >>>> Can you tell us what are your needs and why you would like to use #become:? >>>> or you just want to know about it? >>>> >>>> >>>>> I googled a little but I couldn't find anything more concrete. >>>>> >>>>> Does anybody have any link or opinion about that? >>>>> I'd be glad to hear something more about it. >>>>> >>>>> Thx >>>>> >>>>> -- >>>>> Tato zpráva byla vytvořena převratným poštovním klientem Opery: >>>>> http://www.opera.com/mail/ >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> Tato zpráva byla vytvořena převratným poštovním klientem Opery: >>> http://www.opera.com/mail/ >>> >> >> > > > -- > Tato zpráva byla vytvořena převratným poštovním klientem Opery: > http://www.opera.com/mail/ >
