Hi.

> The simple one, semantically equivalent to yours is -
> 
> allTrue
>         ^self allSatisfy: [:each | each value]
> 
> The usage pattern is as before:
> 
> {[exp1].
> [exp2].
> [exp3]} allTrue

Eh?  {}'s?  Where did they come from?  Where did #, go?  I thought that
was one of the good points, avoiding creating the collection explicitly
and then just sending messages not to a collection, but to a
condition... oh well, maybe it's just that conditions are a collection
of block contexts.  So ok, let's make BooleanCondition a subclass of
OrderedCollection.  Ouch, now #, doesn't work :(.

> The second, smarter one is a bit overly complex, but seems quite
> convenient -
> 
> allTrue
>         ^self allSatisfy: [:e | e isBoolean ifTrue: [e] ifFalse: [e value]]

I don't like the "isBoolean ifTrue: ifFalse:" part.  I just wanted to
group blocks together without an #and: or #or: cascade and treat them as
a single thing.

> So you only put in blocks things you need to calculate lazily, as in -
> {exp1.
> [exp2].
> exp3.
> [exp4]} allTrue
> 
> This is what I meant by not having the block in the example I gave
> below, so I resist your correction! :-)

It was not a correction, it just wanted to make things homogeneous and
simple.

> This allows you to say explicitly "This expression is expensive or
> dangerous!", which is often worth saying. And it reduces clutter
> when they aren't.

Do you think that you can do with

([...], [...], [...]) allTrue

or do you think you'd like

{aBoolean.  [...].  [...]} allTrue

better?  Personally, I'd rather stick with ([...], [...], [...])
allTrue.  I just like it because of the #, syntax.  But I'm still not
sure about whether it would be better to have the BooleanCondition be a
kind of Collection or not.

So I'm torn between syntax and implementation???... what am I thinking
about???  <G>

Andres.