So my usage example would render as -
= aRenameVariableChange 
^[self class = aRenameVariableChange class],
[className = aRenameVariableChange changeClassName],
[isMeta = aRenameVariableChange isMeta],
[oldName = aRenameVariableChange oldName],
[newName = aRenameVariableChange newName] ifAllTrue: [true] 

Well, we could add an allTrue, allFalse message set. Again, to make it a
bit less cluttered, we could make the blocks and booleans polymorphic
here, so

= aRenameVariableChange 
^(self class = aRenameVariableChange class),
[className = aRenameVariableChange changeClassName],
[isMeta = aRenameVariableChange isMeta],
[oldName = aRenameVariableChange oldName],
[newName = aRenameVariableChange newName] allTrue

would work too - you only put in a block things you want compute
conditionally.

The resulting pattern is not bad, but the implementation creeps me out a
bit... adding messages and subclasses to Boolean and BlockContext is a
bit extreme for my taste...

Daniel

Andres Valloud <sqrmax at prodigy.net> wrote:
> Hi.
> 
> I think this could look even better:
> 
> aBlock, anotherBlock, yetAnotherBlock ifAllTrue:... "n-ary and"
> aBlock, anotherBlock, yetAnotherBlock ifAllFalse:... "n-ary and"
> aBlock, anotherBlock, yetAnotherBlock ifAnyTrue:... "n-ary or"
> aBlock, anotherBlock, yetAnotherBlock ifAnyFalse:... "n-ary or"
> 
> where BlockContext>>, is
> 
> , aBlock
> 
> 	^BlockContextComposite with: self with: aBlock
> 
> And where BlockContextComposite is subclass of, say, Boolean (!... but
> it looks ok).  BlockContextComposite would also implement #,.
> 
> The "bad" part is that true and false have to respond to the new
> messages so that true, false and the block context aggregates become
> exchangeable.  However, these messages reduce themselves to applications
> of existing messages in the case of true/false, so they can be
> implemented once only once in Boolean.
> 
> What do you think?
> 
> Andres.