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 <marianopeck@gmail.com> napsal(a):
2011/5/2 info@tomsik.cz <info@tomsik.cz>
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/