[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squeak-dev
Subject:    Re: [squeak-dev] Re: Halt
From:       Nicolas Cellier <nicolas.cellier.aka.nice () gmail ! com>
Date:       2011-08-29 11:43:09
Message-ID: CAKnRiT7omM2VREZC+gMatOEh9kuEVbFovG99YaFRzA+giRT8TQ () mail ! gmail ! com
[Download RAW message or body]

2011/8/29 Bert Freudenberg <bert@freudenbergs.de>:
> On 29.08.2011, at 18:14, DeNigris Sean wrote:
> 
> > What is the purpose of #haltIf: aBlock?
> > 
> > Right now, you can pass any of the following to Object>>haltIf:
> > - aBlock taking an optional argument which is automatically set to the receiver \
> >                 of #halt
> > - aSelector which looks up the call chain and halts if present
> > - aBoolean
> > 
> > So, whatever the condition is, it seems like you should be able to evaluate it in \
> > the calling context. When would you ever need to use a block? Can we eliminate \
> > the block behavior? Or, who has a great war story about blocks saving them from \
> > imminent doom...
> 
> It's useful for testing an intermediate result, without having to declare another \
> temp. E.g.: 
> ^ foo bar + fum
> 
> becomes
> 
> ^ (foo bar haltIf: [:x | x > 42]) + fum
> 
> - Bert -
> 

Ah yes, (Halt if: foo bar > 42) + fum cannot behave correctly and the
intention of (Halt if:foo bar satisfies: [:x | x > 42]) + fum gets a
bit obscured...
I wonder if really used that often (I didn't even know about such
smart message).

Nicolas


[prev in list] [next in list] [prev in thread] [next in thread]