become:
Locked
 
|
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 [hidden email] <[hidden email]>
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. -- Mariano http://marianopeck.wordpress.com |
|
|
In reply to this post by Kamil Tomsik
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 [hidden email] <[hidden email]>: > > 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/ > > |
|
|
In reply to this post by Mariano Martinez Peck
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 <[hidden email]> napsal(a): > 2011/5/2 [hidden email] <[hidden email]> > >> >> 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, [hidden email] 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 <[hidden email]> napsal(a): > >> 2011/5/2 [hidden email] <[hidden email]> >> >>> >>> 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/ > |
|
|
In reply to this post by Mariano Martinez Peck
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 <[hidden email]> napsal(a): > 2011/5/2 [hidden email] <[hidden email]> > >> >> 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/ |
|
|
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 |
|
|
In reply to this post by Kamil Tomsik
On 05/02/2011 09:11 AM, [hidden email] 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 |
|
|
In reply to this post by Stéphane Ducasse
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 <[hidden email]> napsal(a): > Do not use become: for state pattern. It is not worth. > > Stef > > On May 2, 2011, at 3:11 PM, [hidden email] 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 >> <[hidden email]> napsal(a): >> >>> 2011/5/2 [hidden email] <[hidden email]> >>> >>>> >>>> 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, [hidden email] 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 |
|
|
In reply to this post by Kamil Tomsik
2011/5/2 [hidden email] <[hidden email]> Thx, can you be more specific? I'm looking for reasons. 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) -- Mariano http://marianopeck.wordpress.com |
|
|
In reply to this post by Kamil Tomsik
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, [hidden email] 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 <[hidden email]> napsal(a): > >> Do not use become: for state pattern. It is not worth. >> >> Stef >> >> On May 2, 2011, at 3:11 PM, [hidden email] 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 <[hidden email]> napsal(a): >>> >>>> 2011/5/2 [hidden email] <[hidden email]> >>>> >>>>> >>>>> 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/ > |
|
|
In reply to this post by Markus Fritsche-3
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 <[hidden email]> wrote:
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 :) -- -- Mariano http://marianopeck.wordpress.com |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |