On 25 June 2013 11:54, Henrik Johansen <[email protected]> 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 <[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). > > > 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.
