New idiom for conditional testing?
Markus Gaelli
gaelli at emergent.de
Sat Sep 29 16:50:20 UTC 2001
Hi Daniel,
though I think, it's quite new, as I've missed it before, but:
Collection >> allSatisfy: aBlock
seems to be there now.
Using accessors for referencing the variables, you could also write
RenameVariableChange>>= aRenameVariableChange
^#(
#(#class #class)
#(#className #changeClassName)
#(#isMeta #isMeta)
#(#oldName #oldName)
#(#newName #newName))
allSatisfy: [:someSymbols|
(self perform: someSymbols first) =
(aRenameVariableChange perform: someSymbols second)]
So why do I need this stupid duplication of symbols? Because of a strange
behaviour of
RenameVariableChange >> changeClassName
^className
I think the RB-makers intended to make clear, that this is not the name of
the class of RenameVariableChange, but they shouldn't have bothered about
this; "change" is already defined in the name of the class, so it is a light
unneccesary duplication. If we renamed this method to
RenameVariableChange >> className
^className
the code above becomes:
RenameVariableChange>>= aRenameVariableChange
^#(#class #className #isMeta #oldName #newName )
allSatisfy: [:aSymbol|
(self perform: aSymbol)=
(aRenameVariableChange perform: aSymbol)]
Better.
But I saw this before, so why not extracting it:
Object >> isEqualTo: anObject inAspects: someSymbols
^someAspects allSatisfy: [:aSymbol |
(self perform: aSymbol) =
(anObject perform: aSymbol)]
And we would get:
RenameVariableChange>>= aRenameVariableChange
^self
isEqualTo: anObject
inAspects: #(#class #className #isMeta #oldName #newName )
Best,
Markus
More information about the Squeak-dev
mailing list
|