Some Self ideas

Matthew S. Davis mdavis at cse.psu.edu
Thu Jan 18 19:32:04 UTC 2001


Hi Diego,

     Hmmm - when I read the original post I still get the impression that
the intent is to remove blocks from ifTrue:ifFalse:.  Maybe I'm just
missing something in the original post.  Could you clarify what you mean
for me then?  It's the first example that has me thinking that the
intent is to remove blocks...  Here's the relevant part of the original
post:

>I think that Squeak can include two messages (like Self) in Object that
>can be very usefull.
>
>One is:
>
>Object>>value
>    ^ self
>
>In these way, all objects become polymorphic with blocks, so we can
>type:
>
>someVar := someCondition ifTrue:1 ifFalse:2.
>
>instead of
>
>someVar := someCondition ifTrue:[1] ifFalse:[2].
>
>Actually the Squeak compiler does not permit other parameters than a
>Block in these expression

     -Hank

On Thu, 18 Jan 101, Diego Gomez Deck wrote:

> I never suggested to remove the blocks!!! only make Object and Block
> polymorphic with respect to #value....
> 
> TIA,
> 
> Diego Gomez Deck
> 
> >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.
> >> 	
> >>
> >>
> >
> >
> 
> 





More information about the Squeak-dev mailing list