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 <[email protected]> > 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. > >
