"Change Set: removeCannotInterp Date: 13 April 2003 Author: Marcus Denker
1) removes Object>>cannotInterpret:
This method is identical to the one allready defined in ProtoObject, and thus not needed
2) refactors ProtoObject>>cannotInterpret: to use ifNotNil: instead of '== nil ifFalse' and ifNotNil:ifNil instead of 'notNil ifTrue:ifFalse' "!
Hi marcus
I have a question regarding the second refactorings. I was always hesitating about changing the code like that because of lack of clear idea ;)
When I have a code that use the internal representation directly I prefer to use a public method this way subclasses may redefine it without copy and paste. Example:
whichClassIncludesSelector: aSymbol (self includesSelector: aSymbol) ifTrue: [^ self]. superclass == nil ifTrue: [^ nil]. ^ superclass whichClassIncludesSelector: aSymbol
versus
whichClassIncludesSelector: aSymbol (self methodDict includeKey: aSymbol) ifTrue: [^ self]. superclass == nil ifTrue: [^ nil]. ^ superclass whichClassIncludesSelector: aSymbol
Now for == nil ifFalse I do not know. I always have the impression (Wrong I guess too) that for really small images this could have incident but I'm not sure because inlining a method instead of calling it will certainly take more space.
Any hints about that.
Stef
On Sunday, April 13, 2003, at 03:08 PM, Marcus Denker wrote:
"Change Set: removeCannotInterp Date: 13 April 2003 Author: Marcus Denker
removes Object>>cannotInterpret:
This method is identical to the one allready defined in ProtoObject, and thus not needed
refactors ProtoObject>>cannotInterpret: to use ifNotNil: instead of '== nil ifFalse' and ifNotNil:ifNil instead of 'notNil ifTrue:ifFalse' "!
-- Marcus Denker marcus@ira.uka.de -- Squeak! http://squeak.de
<removeCannotInterp.1.cs.gz>
Prof. Dr. Stéphane DUCASSE http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes
"The best way to predict the future is to invent it..." Alan Kay.
Open Source Smalltalks: http://www.squeak.org, http://www.gnu.org/software/smalltalk/smalltalk.html Free books for Universities at http://www.esug.org/sponsoring/promotionProgram.html Free Online Book at http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html
On Sun, Apr 13, 2003 at 03:26:20PM +0200, Stephane Ducasse wrote:
Hi marcus
I have a question regarding the second refactorings. I was always hesitating about changing the code like that because of lack of clear idea ;)
The idea is: "If there's a way to express something with less code more clearly, do it". Nothing else.
This helps a) readability and b) should be even less buggier (you need code for bugs, so less code that at the same time communicates more clearly will not introduce new bugs, but most likely reduce bugs)
This is very much like using "isEmpty" instead of "size = 0".
Of Course, you could ask: Why bother with such trivial stuff? We have BIG PROBLEMS, let's do them them first.
The answer is simple: "Refactor the low hanging fruit". If you can't get trivial stuff done, how can you even think about doing the big refactorings?
A BigRefactorings dialog:
SuperEgo: This is never going to work the code is a BigBallOfMud and everything smells. I need to analyze all this HighLevelArchitecture and develop a careful strategy for it.
Id: Refactor the low-hanging fruit.
SuperEgo: But the other architects will laugh at me if they see my code doesn't have a BigPicture in it.
Id: Refactor the low-hanging fruit.
.....
See http://c2.com/cgi/wiki?RefactorLowHangingFruit
Now for == nil ifFalse I do not know. I always have the impression (Wrong I guess too) that for really small images this could have incident but I'm not sure because inlining a method instead of calling it will certainly take more space.
Yes, those refactorings make the code smaller. And this is good.
There could be performance-implications. But we shouldn't optimize before we know that it is needed. (And then: either a) fix the system or b) hack around it in the spacial case where it is needed and DOCUMENT it)
For ifNil, someone allready did a): The whole ifNil: logic is actually inlined by the compiler...
Marcus
[closed]: Object>>cannotInterpret: allready removed.
< I'm a bug-fixing machine! >
This post brought to you by the BugFixArchiveViewer, a handy tool that makes it easy to comment on proposed fixes and enhancements for Squeak. For more information, check out the Web page for the BugFixArchiveViewer project: http://minnow.cc.gatech.edu/squeak/3214
< I'm a bug-fixing machine! >
squeak-dev@lists.squeakfoundation.org
-
Marcus Denker -
marcus＠ira.uka.de
-
Stephane Ducasse