I've heard that become: is considered to be magic and should be avoided and replaced by either AOP or proxies, 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/
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/
-- Mariano http://marianopeck.wordpress.com
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/
Do not use become: for state pattern. It is not worth. Stef On May 2, 2011, at 3:11 PM, info@tomsik.cz 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 <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/
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 <stephane.ducasse@inria.fr> napsal(a):
Do not use become: for state pattern. It is not worth.
Stef
On May 2, 2011, at 3:11 PM, info@tomsik.cz 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 <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/
-- Tato zpráva byla vytvoÅena pÅevratným poÅ¡tovnÃm klientem Opery: http://www.opera.com/mail/
On 05/02/2011 09:36 AM, info@tomsik.cz 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.
I don't know about "right", but I know its exactly how I would expect the code to read. I would expect the open method to be overridden or check state and behave accordingly. If a door cannot be opened, it is just fine if an open method exists.. Think of it this way: My dog can't speak. She can bark, but doesn't do it on command. If I ask a person "What is your name?" I expect an answer. Although the person may choose not to answer or may not be capable of doing so. That does not mean, that myself, as the sender of the message #speak, would not send the message. Its up to the receiver to behave as the receiver will. Forget about the expectation of the sender and focus on the behavior of the receiver. Smalltalk is an exploratory environment. Also don't be so focused on classes, but on objects. ~Jon
2011/5/2 info@tomsik.cz <info@tomsik.cz>
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?)
Yes, you can. #check adoptInstance: or #primitiveChangeClassTo: But again, I am not sure you need this for your example. Did you consider traits? Even so, I don't think that implementing empty methods or throwing errors is that bad. In fact, it looks good for me.
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 < stephane.ducasse@inria.fr> napsal(a):
Do not use become: for state pattern. It is not worth.
Stef
On May 2, 2011, at 3:11 PM, info@tomsik.cz 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 < 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/
-- Tato zpráva byla vytvoÅena pÅevratným poÅ¡tovnÃm klientem Opery: http://www.opera.com/mail/
-- Mariano http://marianopeck.wordpress.com
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, info@tomsik.cz 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 <stephane.ducasse@inria.fr> napsal(a):
Do not use become: for state pattern. It is not worth.
Stef
On May 2, 2011, at 3:11 PM, info@tomsik.cz 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 <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/
-- Tato zpráva byla vytvoÅena pÅevratným poÅ¡tovnÃm klientem Opery: http://www.opera.com/mail/
On 05/02/2011 09:11 AM, info@tomsik.cz 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
Also I would like to know your opinion about #become: inside of collections, (in order to grow them), while I consider this elegant, creating array copy with different size and assigning it would be IMHO less magic. 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/
info@tomsik.cz wrote:
Also I would like to know your opinion about #become: inside of collections, (in order to grow them), while I consider this elegant, creating array copy with different size and assigning it would be IMHO less magic.
Squeak/Pharo does not use become: to grow collections, but hte second approach you mentioned. Not particularily because become: is too much magic, but because become: is a slow operation in the VM they run on. The place this makes a differences functionally, is with streams. Consider the differences to code written: string := String new: 5. writeStream := string writeStream. writeStream nextPutAll: 'aaaaaaaa' In dialects using become, string will most likely be 'aaaaaaaa ' (two 0 characters at end) In dialects not using become, string will most likely be 'aaaaa', and the internal collection of the writeStream a different object entirely. Cheers, Henry -- View this message in context: http://forum.world.st/become-tp3489896p3490015.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Hello, become replaces all pointers to the object to point to some other object. That means that for instance code running in background, that was working with object a will be working with object b the next moment. This can cause all kind of things to break... If somebody debugs your code and doesn't know of the become, he reads the code and cannot see why method "a1" returns object "a" and later, when he debugs method b1, the object is "b". Additionally, pointers in methods pointing to a can cause the VM to crash if a was an integral object. Proxies catch the "doesNotUnderstand" exception and do a dynamic lookup using a mechanism that is not the normal method call. This can be hard to debug to - but it has less chance of a VM crash. Regards, Markus 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,
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/
On 05/02/2011 05:41 AM, Markus Fritsche wrote:
Hello,
become replaces all pointers to the object to point to some other object.
Actually, that's what #becomeForward: does, #become: swaps two objects replacing all pointers to the object to point to some other object and vice versa, which can cause serious issues if you aren't expecting it. #becomeForward: is quite often the behavior you'd want when you think you need #become:. -- Ramon Leon http://onsmalltalk.com
On Mon, May 2, 2011 at 8:20 PM, Ramon Leon <ramon.leon@allresnet.com> wrote:
On 05/02/2011 05:41 AM, Markus Fritsche wrote:
Hello,
become replaces all pointers to the object to point to some other object.
Actually, that's what #becomeForward: does, #become: swaps two objects replacing all pointers to the object to point to some other object and vice versa, which can cause serious issues if you aren't expecting it. #becomeForward: is quite often the behavior you'd want when you think you need #become:.
You know, I always thoguht that #become: is a bad name. For me, #becomeForward: should be called #become and, #become should be called #replace: or #swaps: or something like that, but to make clear that it is both sides :)
-- Ramon Leon http://onsmalltalk.com
-- Mariano http://marianopeck.wordpress.com
participants (7)
-
Henrik Sperre Johansen -
info＠tomsik.cz -
Jon Hancock -
Mariano Martinez Peck -
Markus Fritsche -
Ramon Leon -
Stéphane Ducasse