On 05/02/2011 09:11 AM, [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.
You can simply have the #open method do nothing in certain states, or
throw an exception. No need for messageNotUnderstood. You absoluletly
do not want to use become: for such an example. All in all, I'm not
sure how I feel about creating a new first class object to represent
each of a door's states.
The last time I recall using #become: was for low level and carefully
protected behavior needed by an ORB. become should come with a special
form which needs to go through three levels of sign off before you
should be allowed to use it in your code.
~Jon
