Hi Diego (and everyone else),

     I just wanted to give you one reason why I think Richard has
suggested that the Object>>value idea won't work.  The reason that
ifTrue:ifFalse: uses blocks is because blocks delay execution.  In other
words, you want ifTrue:ifFalse: to only execute one of the possibilities
and not both.  Using a block is a great way to delay their execution
because the block waits until the value message is sent before it executes
the code inside of it.

     Here's a "tangible" example.  Suppose that you have two
instances, a and b, of a class that answers to a message called
incrementValue.  What the incrementValue method actually does is to
increment some instance variable by some amount.  If we implement the
suggestion and then write

cond ifTrue: a incrementValue ifFalse: b incrementValue.

then we will not get the behavior that we want.  In this case, both a and
b end up executing their incrementValue methods regardless of the
condition because we have not delayed their execution.  However,

cond ifTrue: [ a incrementValue ] ifFalse: [ b incrementValue ].

works great since we don't execute both possibilities.

     -Hank

On Thu, 18 Jan 2001, Richard A. O'Keefe wrote:

> Diego Gomez Deck <DiegoGomezDeck at ConsultAr.com> suggested:
>     Object>>value
> 	^ self
> 
> Please, don't anybody do this.  It seems quite common for beginners,
> used to other languages, to write
> 	cond ifTrue: exp1 ifFalse: exp2
> when they really mean
> 	cond ifTrue: [exp1] ifFalse: [exp2].
> 
> The sooner this is rejected, the sooner they understand how ifTrue:ifFalse:
> is supposed to work.
> 	
> 	The other message is:
> 	
> 	Object>>, anObject
> 		^ OrderedCollection with:self with:anObject
> 	
> IMHO, it is helpful if each message means one thing.
> If "a , b" always means "make a new sequence with the elements of a followed
> by the elements of b", I can cope.  But if it means "make a new sequence
> (either with a as an element or the elements of a as elements) followed by
> the elements of b", I'll get lost.  The more complicated the description
> of a method, the harder it is to use.
> 	
> 
>