- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Object >> #is:

by Esteban Lorenzano

I really cannot believe that you can consider is: #string better programing than isString no matter the implementation, and no matter if you can still found senders of #string... string programming (or symbol programing) is just bad, bad, bad. Is so bad that is axiomatic... I cannot even explain why... :) and that just because we do not like to have 20 methods (or whatever the number) isBlah in object? sorry, I completely disagree with the idea. now, I agree that some of the "is" methods should be removed, but that is a complete different discussion :) Esteban On Jun 25, 2013, at 1:22 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 June 2013 12:59, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >> On 25 juin 2013, at 11:45, Igor Stasenko wrote: >> >> On 25 June 2013 11:09, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >> >> On 25 juin 2013, at 10:28, Esteban Lorenzano wrote: >> >> >> >> On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> >> >> On 2013-06-24, at 18:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> >> >> the isBlah is not optimal now it is just there and we cannot rewrite >> >> everything. >> >> >> I still think that is: is a nice way to kill some of the isPlague in Object. >> >> >> >> I still don't see what you solve, and the idea to use symbols for #is: is >> >> also >> >> >> wrong, for me that's going back to string-based programming. >> >> >> >> well, that's basically my argument agains #is: >> >> IMO is also an important performance issue in many cases, because is >> >> replacing a simple send with a string comparison and that can provoke >> >> slowdowns in some places (no idea where, this is just theoretical :)... >> >> Of course, as "pharo designers" we should be careful on not overpopulate >> >> Object with isBlah methods... but sometimes they are needed :) >> >> >> >> +1. >> >> Indeed, sometimes they are needed. You can't replace every isXXX send with a >> >> new visitor or dispatching by adding more and more extension methods all >> >> over the place (including Object BTW). >> >> Yet a fair amount of these methods can be removed. >> >> I think that a lot of these methods exist only because people think that >> >> isKindOf:/isMemberOf: are always evil, and its not true. >> >> There is at least three cases were I don't feel guilty using >> >> isKindOf:/isMemberOf: : >> >> - In unit tests >> >> - In #= methods >> >> - When I really want to ensure that an object is an instance of a specific >> >> class (see MethodContext>>#privRefreshWith: for example). This poor's man >> >> type checking can be replace with typed slots (that end up using >> >> isKindOf/isMemberOf: anyway). >> >> If we agree on that we can remove many #isXXX methods. >> >> Then there is some #isXXX methods that do not belong to Object (ex: >> >> #isTransferable belongs to Morph) and others that can be removed just by >> >> refactoring senders. >> >> We can also move some of them to extension methods, that doesn't solve the >> >> problem but it's a better packaging. >> >> Anyway I don't want to rely on #is: method because it conflates a lot of >> >> selectors into one. >> >> >> yes. it is. so what is the problem? >> >> >> The problem is that this #is: method is like aspirin: it makes the symptom >> disappear but it doesn't cure the disease (if there is one). >> > > Why? It was proposed how to deal with too many isXXXX methods in Object class. > It is orthogonal to whether you should use isXXX pattern or not. > Because each case should be dealt separately (and that's where you > free to override #is: method > to serve your special purpose). > >> Are you sure you understand the purpose of #is: method? >> >> >> No I didn't, but now that you revealed me the true purpose of #is:, I >> finally reached enlightenment. >> But apparently it's not the case of its own comment. >> > Despite the method's comment contains my name, it is not under my authorship. > Look for mailing list archives to see what i proposed then, and if it > different to what i saying now. > >> "A means for cleanly replacing all isXXX like methods. >> Please use judiciously! >> Suggested by Igor Stasenko at >> >> all isXXX should be converted following the pattern >> ColorForm>>isColorForm >> ^ true >> Object>>isColorForm >> ^ false >> is: aSymbol >> ^ aSymbol = #ColorForm or: [ super is: aSymbol ]" >> >> its purpose is for cases when you realy realy very very badly want to >> add own isPlague to >> Object protocol. In that case, you should use 'is: #plague' >> because no new isXXXX methods should be added anymore. >> The feast is over, and you should use #is: method. (or think how to >> not use isXXX pattern at all). >> >> >> TL;DR: I agree with Camillo :) >> >> >> >> anyway, this topic has been discussed with enough hot air so far and no >> >> progress, >> >> >> which means it is absolutely not important. there are more urgent things to >> >> done... >> > > i could not care less.. Back in 2009 i just proposed this. > Pharo people seems liked the idea and added this method into the image. > That's how my name appeared there. > And what i trying to (again as in 2009) articulate here, is how i see > to use this method. > But NOT whether it should stay in image or to be gone. > > > > -- > Best regards, > Igor Stasenko. >

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by Igor Stasenko

On 25 June 2013 12:59, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 25 juin 2013, at 11:45, Igor Stasenko wrote: > > On 25 June 2013 11:09, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > > On 25 juin 2013, at 10:28, Esteban Lorenzano wrote: > > > > On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > > On 2013-06-24, at 18:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > > the isBlah is not optimal now it is just there and we cannot rewrite > > everything. > > > I still think that is: is a nice way to kill some of the isPlague in Object. > > > > I still don't see what you solve, and the idea to use symbols for #is: is > > also > > > wrong, for me that's going back to string-based programming. > > > > well, that's basically my argument agains #is: > > IMO is also an important performance issue in many cases, because is > > replacing a simple send with a string comparison and that can provoke > > slowdowns in some places (no idea where, this is just theoretical :)... > > Of course, as "pharo designers" we should be careful on not overpopulate > > Object with isBlah methods... but sometimes they are needed :) > > > > +1. > > Indeed, sometimes they are needed. You can't replace every isXXX send with a > > new visitor or dispatching by adding more and more extension methods all > > over the place (including Object BTW). > > Yet a fair amount of these methods can be removed. > > I think that a lot of these methods exist only because people think that > > isKindOf:/isMemberOf: are always evil, and its not true. > > There is at least three cases were I don't feel guilty using > > isKindOf:/isMemberOf: : > > - In unit tests > > - In #= methods > > - When I really want to ensure that an object is an instance of a specific > > class (see MethodContext>>#privRefreshWith: for example). This poor's man > > type checking can be replace with typed slots (that end up using > > isKindOf/isMemberOf: anyway). > > If we agree on that we can remove many #isXXX methods. > > Then there is some #isXXX methods that do not belong to Object (ex: > > #isTransferable belongs to Morph) and others that can be removed just by > > refactoring senders. > > We can also move some of them to extension methods, that doesn't solve the > > problem but it's a better packaging. > > Anyway I don't want to rely on #is: method because it conflates a lot of > > selectors into one. > > > yes. it is. so what is the problem? > > > The problem is that this #is: method is like aspirin: it makes the symptom > disappear but it doesn't cure the disease (if there is one). > Why? It was proposed how to deal with too many isXXXX methods in Object class. It is orthogonal to whether you should use isXXX pattern or not. Because each case should be dealt separately (and that's where you free to override #is: method to serve your special purpose). > Are you sure you understand the purpose of #is: method? > > > No I didn't, but now that you revealed me the true purpose of #is:, I > finally reached enlightenment. > But apparently it's not the case of its own comment. > Despite the method's comment contains my name, it is not under my authorship. Look for mailing list archives to see what i proposed then, and if it different to what i saying now. > "A means for cleanly replacing all isXXX like methods. > Please use judiciously! > Suggested by Igor Stasenko at > > all isXXX should be converted following the pattern > ColorForm>>isColorForm > ^ true > Object>>isColorForm > ^ false > is: aSymbol > ^ aSymbol = #ColorForm or: [ super is: aSymbol ]" > > its purpose is for cases when you realy realy very very badly want to > add own isPlague to > Object protocol. In that case, you should use 'is: #plague' > because no new isXXXX methods should be added anymore. > The feast is over, and you should use #is: method. (or think how to > not use isXXX pattern at all). > > > TL;DR: I agree with Camillo :) > > > > anyway, this topic has been discussed with enough hot air so far and no > > progress, > > > which means it is absolutely not important. there are more urgent things to > > done... > i could not care less.. Back in 2009 i just proposed this. Pharo people seems liked the idea and added this method into the image. That's how my name appeared there. And what i trying to (again as in 2009) articulate here, is how i see to use this method. But NOT whether it should stay in image or to be gone. -- Best regards, Igor Stasenko.

June 25, 2013

[update 3.0] #30219

by Esteban Lorenzano

30219 ----- 10735 Cleaning ImageMorph API use form: for ImageMorph new form: ... and not image because image does not convey what is expected. https://pharo.fogbugz.com/default.asp?10735 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-EstebanLorenzano… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-EstebanLore… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusCommon-EstebanLorenza… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-EstebanLorenzano.480… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-EstebanLorenzano… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Growl-EstebanLorenzano.19.diff

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by Camille Teruel

On 25 juin 2013, at 11:45, Igor Stasenko wrote: > On 25 June 2013 11:09, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >> On 25 juin 2013, at 10:28, Esteban Lorenzano wrote: >> >> >> On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> >> On 2013-06-24, at 18:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> >> the isBlah is not optimal now it is just there and we cannot rewrite >> everything. >> >> I still think that is: is a nice way to kill some of the isPlague in Object. >> >> >> I still don't see what you solve, and the idea to use symbols for #is: is >> also >> >> wrong, for me that's going back to string-based programming. >> >> >> well, that's basically my argument agains #is: >> IMO is also an important performance issue in many cases, because is >> replacing a simple send with a string comparison and that can provoke >> slowdowns in some places (no idea where, this is just theoretical :)... >> Of course, as "pharo designers" we should be careful on not overpopulate >> Object with isBlah methods... but sometimes they are needed :) >> >> >> +1. >> Indeed, sometimes they are needed. You can't replace every isXXX send with a >> new visitor or dispatching by adding more and more extension methods all >> over the place (including Object BTW). >> Yet a fair amount of these methods can be removed. >> I think that a lot of these methods exist only because people think that >> isKindOf:/isMemberOf: are always evil, and its not true. >> There is at least three cases were I don't feel guilty using >> isKindOf:/isMemberOf: : >> - In unit tests >> - In #= methods >> - When I really want to ensure that an object is an instance of a specific >> class (see MethodContext>>#privRefreshWith: for example). This poor's man >> type checking can be replace with typed slots (that end up using >> isKindOf/isMemberOf: anyway). >> If we agree on that we can remove many #isXXX methods. >> Then there is some #isXXX methods that do not belong to Object (ex: >> #isTransferable belongs to Morph) and others that can be removed just by >> refactoring senders. >> We can also move some of them to extension methods, that doesn't solve the >> problem but it's a better packaging. >> Anyway I don't want to rely on #is: method because it conflates a lot of >> selectors into one. >> > yes. it is. so what is the problem? The problem is that this #is: method is like aspirin: it makes the symptom disappear but it doesn't cure the disease (if there is one). > Are you sure you understand the purpose of #is: method? No I didn't, but now that you revealed me the true purpose of #is:, I finally reached enlightenment. But apparently it's not the case of its own comment. "A means for cleanly replacing all isXXX like methods. Please use judiciously! Suggested by Igor Stasenko at http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html. all isXXX should be converted following the pattern ColorForm>>isColorForm ^ true Object>>isColorForm ^ false is: aSymbol ^ aSymbol = #ColorForm or: [ super is: aSymbol ]" > its purpose is for cases when you realy realy very very badly want to > add own isPlague to > Object protocol. In that case, you should use 'is: #plague' > because no new isXXXX methods should be added anymore. > The feast is over, and you should use #is: method. (or think how to > not use isXXX pattern at all). > >> >> TL;DR: I agree with Camillo :) >> >> >> anyway, this topic has been discussed with enough hot air so far and no >> progress, >> >> which means it is absolutely not important. there are more urgent things to >> done... >> > > > -- > Best regards, > Igor Stasenko. >

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by Igor Stasenko

On 25 June 2013 12:47, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > But in some cases, you will end up with an object that is more than one > thing: > - a Number > - an Integer > - a Fraction > For example 0 shall answer yes to these 3. > So ^foo == #specialName just does not work, or you end up with caseOf: > err, why? if you define it like: Number>>is: symbol ^ symbol == #number 0 is: #number => true 0.0 is: #number => true 0/1 is: #number => true ? It is actually up to implementor how to his own classes should process #is: message. The only invariant (which imo best one), that Object should always answer false to #is: message no matter what parameter you passed, to avoid any ambiguous cases and keep things simple and easy to remember. That means, that unless you override this method in own class, its instances will always answer false to #is: message. And when you override it, you are free to define it the way you like... MyClass>>is: foo ^ foo class == self class or MyClass>>is: foo ^ foo class name == self class name or MyClass>>is: foo ^ foo isKindOf: MyClass (no limits to imagination :) -- Best regards, Igor Stasenko.

June 25, 2013

Re: [Pharo-dev] why so many processes are running at startup time?

by Igor Stasenko

On 24 June 2013 11:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Igor, > > On 21 Jun 2013, at 13:27, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Yes, the only thing i hate in this code is references to many different classes. >> These processes actually represent various basic services of the system. >> so i would prefer that these services register themselves somewhere, >> like that we could have a clean code, something like: >> >> services collect: [:each | each process ] >> >> like that, you don't need to modify this method evry time you changing >> the list/implementation etc. > > I implemented this on ReleaseTest, with a fixed list, for now. > > I understand your remark: some form of dependency injection is cleaner and more extensible/scaleable indeed. > > However, in this particular case, I am not 100% convinced: your dynamic list based on registration can only be as good as the registrars, if they make a mistake (failing to unregister), the list will become bad. > there can be a compromise :) a) make method, which contains list of exact class names (services) b) make sure that these classes understand same protocol, so that in other method you do: self services collect: [:each | each processThatIsValidWhatever ] > Sven > >>> Sven >>> >>>> and get 6 processes remain: >>>> (80) 745275392: Delay class>>handleTimerEvent >>>> (60) Input events fetching process: InputEventFetcher>>waitForInput >>>> (60) 1061945344: SmalltalkImage>>lowSpaceWatcher >>>> (50) 946339840: WeakArray class>>finalizationProcess >>>> (40s) Morphic UI process: nil >>>> (10) 845938688: ProcessorScheduler class>>idleProcess >>>> >>>> is this OK? >>>> >>>> regards. >>>> >>>> >>>> 2013/6/20 Marcus Denker <marcus.denker(a)inria.fr> >>>> Hi, >>>> >>>> I think we should for now just kill them when building the image, I will check. >>>> >>>> On Jun 20, 2013, at 9:56 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>>> >>>>> Hello, >>>>> >>>>> These processes are due to the new integration testing process. This new process was introduced in Pharo 3.0 alpha, and we found the bug and fixed it. >>>>> Recently we backport the new integration process to Pharo 2.0 and seemingly it created the same bug but since we read your mail we were not aware of it. We need to backport the fix. >>>>> We will fix that within a few days. >>>>> >>>>> As a workaround, you can just kill these processes in your image for now ... >>>>> >>>>> Thanks for reporting the issue, >>>>> >>>>> >>>>> >>>>> >>>>> 2013/6/20 NISHIHARA Satoshi <goonsh(a)gmail.com> >>>>> There are 30 over processes are running at startup, Pharo-20607.image. >>>>> >>>>> <NDOWS-1252?B?vIgyMDEzLTA2LTIwIDEzLjE5LjU277yJLnBuZw=.png> >>>>> >>>>> regards. >>>>> >>>>> -- >>>>> -- >>>>> "NISHIHARA Satoshi" >>>>> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] >>>>> >>>>> >>>>> >>>>> -- >>>>> ClÃ©ment BÃ©ra >>>>> Mate Virtual Machine Engineer >>>>> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >>>> >>>> >>>> >>>> >>>> -- >>>> -- >>>> "NISHIHARA Satoshi" >>>> [:goonsh :nsh | ^ nishis perform: goonsh with: nsh] >>> >>> >> >> >> > > -- Best regards, Igor Stasenko.

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by Nicolas Cellier

But in some cases, you will end up with an object that is more than one thing: - a Number - an Integer - a Fraction For example 0 shall answer yes to these 3. So ^foo == #specialName just does not work, or you end up with caseOf: 2013/6/25 Igor Stasenko <siguctua(a)gmail.com> > On 25 June 2013 11:54, Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > > > On Jun 25, 2013, at 11:09 AM, Camille Teruel wrote: > > > > > > On 25 juin 2013, at 10:28, Esteban Lorenzano wrote: > > > > > > On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > > > > > > On 2013-06-24, at 18:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > > > > the isBlah is not optimal now it is just there and we cannot rewrite > > everything. > > > > I still think that is: is a nice way to kill some of the isPlague in > Object. > > > > > > I still don't see what you solve, and the idea to use symbols for #is: is > > also > > > > wrong, for me that's going back to string-based programming. > > > > > > well, that's basically my argument agains #is: > > IMO is also an important performance issue in many cases, because is > > replacing a simple send with a string comparison and that can provoke > > slowdowns in some places (no idea where, this is just theoretical :)... > > Of course, as "pharo designers" we should be careful on not overpopulate > > Object with isBlah methods... but sometimes they are needed :) > > > > > > +1. > > Indeed, sometimes they are needed. You can't replace every isXXX send > with a > > new visitor or dispatching by adding more and more extension methods all > > over the place (including Object BTW). > > > > > > While dispatch is a valid substitute, it: > > 1) Doesn't pollute Object any less, like you say (you still need a > > handleXYZ: method on Object replacing the previous isX, now doing > nothing) > > 2) Breaks up the flow of the code, making it harder to get a good picture > > without 948 implementors open. > > > > Yet a fair amount of these methods can be removed. > > I think that a lot of these methods exist only because people think that > > isKindOf:/isMemberOf: are always evil, and its not true. > > There is at least three cases were I don't feel guilty using > > isKindOf:/isMemberOf: : > > - In unit tests > > - In #= methods > > - When I really want to ensure that an object is an instance of a > specific > > class (see MethodContext>>#privRefreshWith: for example). This poor's man > > type checking can be replace with typed slots (that end up using > > isKindOf/isMemberOf: anyway). > > > > > > For me, this has the same fundamental problem as using is:. > > If you were to, for example, write isKindOf: Number instead of isNumber, > try > > quickly identifying the places that is being used without doing a full > text > > search. > > You can't search for Number, lest you want to sift through all > references to > > the class, and you can't search for isKindOf: without wading through its > > uses with all other classes. > > The degree to which this is a problem differs of course. > > > > #is: method does not have such problem. > Object>>is: foo > ^ false > > MyClass>>is: foo > ^ foo == #specialName > > > to look for all uses of #specialName, you can just browse senders of it. > And it will give you exact number and places, without need to do a > full-text search. Simple and easy isn't? > > That's of course, how i would use it... > But when people proposing to add some 'more useful' forms > of it, like comparing class name, or class , or even strings, in > default implementation, things get more complicated, > and you no longer sure how to find all uses for your case. > Instead, if we keep things simple and restrict that parameter should > be a symbol, and default implementation (in Object) always answers > false, > this will make things much easier to deal with in foreseen future. > > Now, if people do not like it, and do not want it.. so, lets keep > using our beloved isKindOf: and friends.. > every time i see how people use them, i get a warm fuzzy feeling :) > > > If we agree on that we can remove many #isXXX methods. > > Then there is some #isXXX methods that do not belong to Object (ex: > > #isTransferable belongs to Morph) and others that can be removed just by > > refactoring senders. > > We can also move some of them to extension methods, that doesn't solve > the > > problem but it's a better packaging. > > Anyway I don't want to rely on #is: method because it conflates a lot of > > selectors into one. > > > > > > +1 > > The longer I maintain Smalltalk code, the more I appreciate specific > > selectors like #fromADomainObject: / #atMyTypeOfData:. > > Makes refactoring and reasoning about a "dead" image much, much, easier. > > > > Having my Object class unpolluted comes much further down my list of > "nice > > to haves", if it can't be rewritten/safely hoisted to an appropriate > > subclass, making them extensions are more than enough imho. > > > > In general, the more methods we put into Object, the higher > probability of name clashing (two projects using same selector > for method in Object but for different purpose). > It also slows down the lookup time, because VM checks every method > dictionary, including Object. > (not speaking of slowing down UI ;) > > > Cheers, > > Henry > > > -- > Best regards, > Igor Stasenko. > >

June 25, 2013

Re: [Pharo-dev] Object >> #is:

by Igor Stasenko

On 25 June 2013 11:54, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Jun 25, 2013, at 11:09 AM, Camille Teruel wrote: > > > On 25 juin 2013, at 10:28, Esteban Lorenzano wrote: > > > On Jun 24, 2013, at 6:59 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > On 2013-06-24, at 18:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > the isBlah is not optimal now it is just there and we cannot rewrite > everything. > > I still think that is: is a nice way to kill some of the isPlague in Object. > > > I still don't see what you solve, and the idea to use symbols for #is: is > also > > wrong, for me that's going back to string-based programming. > > > well, that's basically my argument agains #is: > IMO is also an important performance issue in many cases, because is > replacing a simple send with a string comparison and that can provoke > slowdowns in some places (no idea where, this is just theoretical :)... > Of course, as "pharo designers" we should be careful on not overpopulate > Object with isBlah methods... but sometimes they are needed :) > > > +1. > Indeed, sometimes they are needed. You can't replace every isXXX send with a > new visitor or dispatching by adding more and more extension methods all > over the place (including Object BTW). > > > While dispatch is a valid substitute, it: > 1) Doesn't pollute Object any less, like you say (you still need a > handleXYZ: method on Object replacing the previous isX, now doing nothing) > 2) Breaks up the flow of the code, making it harder to get a good picture > without 948 implementors open. > > Yet a fair amount of these methods can be removed. > I think that a lot of these methods exist only because people think that > isKindOf:/isMemberOf: are always evil, and its not true. > There is at least three cases were I don't feel guilty using > isKindOf:/isMemberOf: : > - In unit tests > - In #= methods > - When I really want to ensure that an object is an instance of a specific > class (see MethodContext>>#privRefreshWith: for example). This poor's man > type checking can be replace with typed slots (that end up using > isKindOf/isMemberOf: anyway). > > > For me, this has the same fundamental problem as using is:. > If you were to, for example, write isKindOf: Number instead of isNumber, try > quickly identifying the places that is being used without doing a full text > search. > You can't search for Number, lest you want to sift through all references to > the class, and you can't search for isKindOf: without wading through its > uses with all other classes. > The degree to which this is a problem differs of course. > #is: method does not have such problem. Object>>is: foo ^ false MyClass>>is: foo ^ foo == #specialName to look for all uses of #specialName, you can just browse senders of it. And it will give you exact number and places, without need to do a full-text search. Simple and easy isn't? That's of course, how i would use it... But when people proposing to add some 'more useful' forms of it, like comparing class name, or class , or even strings, in default implementation, things get more complicated, and you no longer sure how to find all uses for your case. Instead, if we keep things simple and restrict that parameter should be a symbol, and default implementation (in Object) always answers false, this will make things much easier to deal with in foreseen future. Now, if people do not like it, and do not want it.. so, lets keep using our beloved isKindOf: and friends.. every time i see how people use them, i get a warm fuzzy feeling :) > If we agree on that we can remove many #isXXX methods. > Then there is some #isXXX methods that do not belong to Object (ex: > #isTransferable belongs to Morph) and others that can be removed just by > refactoring senders. > We can also move some of them to extension methods, that doesn't solve the > problem but it's a better packaging. > Anyway I don't want to rely on #is: method because it conflates a lot of > selectors into one. > > > +1 > The longer I maintain Smalltalk code, the more I appreciate specific > selectors like #fromADomainObject: / #atMyTypeOfData:. > Makes refactoring and reasoning about a "dead" image much, much, easier. > > Having my Object class unpolluted comes much further down my list of "nice > to haves", if it can't be rewritten/safely hoisted to an appropriate > subclass, making them extensions are more than enough imho. > In general, the more methods we put into Object, the higher probability of name clashing (two projects using same selector for method in Object but for different purpose). It also slows down the lookup time, because VM checks every method dictionary, including Object. (not speaking of slowing down UI ;) > Cheers, > Henry -- Best regards, Igor Stasenko.

June 25, 2013

Re: [Pharo-dev] Conflict merging resolution is a bit doomed :)

by Camillo Bruni

I don't understand. If you merge and recommit it is fine, since the new slice will have different ancestors the 3-way merge won't complain a second time, no? On 2013-06-25, at 11:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I do not know how I can republish a Slice when there is a conflict. Especially when I merged and say that I want to keep the change I did. So we are in the deadlock. There is no way for the fix producers to indicate that > he merged and that his changes should be keep. > > So from a bug integration process this is not really good. > > Stef

June 25, 2013

Re: [Pharo-dev] [update 2.0] #20608

by Max Leske

On 25.06.2013, at 11:33, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 20608 > ----- > > 10888 Backport 2.0: Compound Extension Methods Unpackaged > https://pharo.fogbugz.com/f/cases/10888/Backport-2-0-Compound-Extension-Met… > > 10730 Fix for stack serialization with Fuel > https://pharo.fogbugz.com/f/cases/10730/Fix-for-stack-serialization-with-Fu… Thanks Esteban! > > 10994 Backport 2.0: Delays do not work properly directly on image startup > https://pharo.fogbugz.com/f/cases/10994/Backport-2-0-Delays-do-not-work-pro… > > Diff information: > http://ss3.gemstone.com/ss/Pharo20/RPackage-Tests-EstebanLorenzano.111.diff > http://ss3.gemstone.com/ss/Pharo20/RPackage-Core-EstebanLorenzano.216.diff > http://ss3.gemstone.com/ss/Pharo20/Kernel-EstebanLorenzano.1348.diff > http://ss3.gemstone.com/ss/Pharo20/FuelTests-EstebanLorenzano.316.diff > http://ss3.gemstone.com/ss/Pharo20/Fuel-EstebanLorenzano.767.diff > >

June 25, 2013