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 <camillobr...@gmail.com> wrote: >> >>> >>> On 2013-06-24, at 18:55, Stéphane Ducasse <stephane.duca...@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. > 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. Cheers, Henry
