Alejandro F. Reimondo alereimondo at
Fri May 29 19:29:55 UTC 1998

Yes, yes, & yes.
You are right.
I will change Actions implementation soon.

when I saw #evaluate (& #evaluate:) the first time, it sounds wrong to me...
Later I say, why PPD people has used #evaluate and not #value ?
Then I thought (provably more than needed to arrive a good answer ;-) )

" When I say value to anObject I want to know it's value
 and when I say evaluate I want to know the result of evaluating an object...
For (runnable/)evaluable objects there is a difference (#value returns the
 object and #evaluates returns an object result of evaluation)...
Provably blocks returns it's evaluation result as value... "

Do you understand what happened?
I found a way to justify #evaluate in my mind, because PPD didn't use #value.
two times wrong. :-)


Desde: 	Ralph E. Johnson[SMTP:johnson at]
Enviado el: 	Viernes 29 de Mayo de 1998 10:46
Para: 	squeak at
Cc: 	alereimondo at
Asunto: 	RE: Pluggability

I looked at Actions, and liked what I saw.  I've seen and done things
like that before.  My main complaint is that the method should be
#value and #value:, not #evaluate and #evaluate:  A block is a 
built-in Action, and it already defines a protocol, so we should
use it.  

One of the interesting things is that Actions define both #value
and #evaluate.  So, you can use an Action instead of a block, but
you can't use a block instead of an Action.  Why?  A block is just
a built-in Action.  Now, the fileIn defines #evaluate and #evaluate:
for blocks, but that does not passify me!  We should not proliferate
protocols, and #value and #value: are well defined and short.
They are not particular logical, but that is not so important for
the most common messages.  #at:put: is not particularly logical, either.

It is a mistake to put #evaluate and #evaluate: in Object.
ParcPlace did this with #value and #value: for awhile, and the
problem is that you lose useful information because errors don't
get caught right away but the system keeps on running for awhile
before finally noticing some error.  It is so easy to convert
an object into an Action (just send #asAction to it) that you don't
need these helper methods in Object.  Further, using #asAction
provides helpful information to the reader that an object is
going to be used as an action, so it gives hints that can prevent
the reader from having to keep on reading.

BlockContext should define asAction to return self, not to make
a new action that returns itself.  A block is just a built-in action.

(I'm hoping that if I say it enough, people will believe me!)

Blocks should also have , defined to be the same as in Action.

There is no reason for ActionSecuence, and its comment should
be moved to ActionComposite.  I like CompositeAction better as
a name, by the way.  It follows Kent Beck's pattern for naming
subclasses, which I think describes the way most experienced 
Smalltalkers do it.


More information about the Squeak-dev mailing list