On 25 June 2013 12:59, Camille Teruel <[email protected]> wrote: > > On 25 juin 2013, at 11:45, Igor Stasenko wrote: > > On 25 June 2013 11:09, Camille Teruel <[email protected]> wrote: > > > On 25 juin 2013, at 10:28, Esteban Lorenzano wrote: > > > > On Jun 24, 2013, at 6:59 PM, Camillo Bruni <[email protected]> wrote: > > > > On 2013-06-24, at 18:55, Stéphane Ducasse <[email protected]> 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.
