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/
