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