May 2011 - Pharo-users - lists.pharo.org

Re: [Pharo-users] become:

by StÃ©phane Ducasse

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

May 2, 2011

Re: [Pharo-users] become:

by Mariano Martinez Peck

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

May 2, 2011

Re: [Pharo-users] become:

by Jon Hancock

On 05/02/2011 09:36 AM, info(a)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

May 2, 2011

Re: [Pharo-users] Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173

by Igor Stasenko

On 2 May 2011 00:48, Markus Fritsche <fritsche.markus(a)googlemail.com> wrote: > Hi, > > 2011/4/27 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> And as Marcus said, most of the times (sometimes we had some problems) we >> have a deprecation process where we (usually) say which should be used >> instead. > > From a a-little-bit-more-than-user perspective I am looking at > > SmalltalkImage>>#hasBindingThatBeginsWith: aString > Â Â Â self deprecated: 'Use Smalltalk globals'. > Â Â Â ^globals hasBindingThatBeginsWith: aString > > Well, with a bit of analysis, I would be able to figure out, that the > author might have intended that I should search the SystemDictionary > myself. I feel like an additional comment would have been helpful. > > Same with the other problem I had with ServiceRegistry - it is gone > and it is not easy to find out what that was supposed to do. Next step > is to compare squeak and the Pharo releases to find out what happened > to it (the issue tracker does not easily yield results for this, but > maybe I searched in the wrong way). > > I know there is no easy fix for this, as "fast deprecation" was what > made Pharo manageable compared to other image-based smalltalk dialects > (not to mention anything specific ;)) but there is a lot of > interesting code on squeaksource that naturally breaks - for those > interested in that code, it would be helpful to give a bit more advice > on "porting" and "the path of deprecation". > An advice is simple: 1. try loading the code using most recent image, try running it. 2. fix errors & bugs you found 3. Repeat from 1. This is what package maintainers should usually do all the time. And there is no magic: you have to get your hands dirty and make things work (again). Now, if nobody doing it for years, its not a Pharo failure that some code turned to be broken. I like that pharoers are not afraid to break things (of course if they breaking them for good ;). And besides.. you can always use years old image and happily load all code in it and it will work there. So, you are free to choose either: - stay with old image version where all dusty code working - running your code on most recent Pharo version and using its new features :) -- Best regards, Igor Stasenko AKA sig.

May 2, 2011

Re: [Pharo-users] become:

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

May 2, 2011

Re: [Pharo-users] become:

by Jon Hancock

On 05/02/2011 09:11 AM, info(a)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

May 2, 2011

Re: [Pharo-users] become:

by Henrik Sperre Johansen

info(a)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.

May 2, 2011

Re: [Pharo-users] become:

by info＠tomsik.cz

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

May 2, 2011

Re: [Pharo-users] become:

by info＠tomsik.cz

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

May 2, 2011

Re: [Pharo-users] become:

by Markus Fritsche

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(a)tomsik.cz <info(a)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/ > >

May 2, 2011