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. :-)
Ale.
---------- Desde: Ralph E. Johnson[SMTP:johnson@cs.uiuc.edu] Enviado el: Viernes 29 de Mayo de 1998 10:46 Para: squeak@cs.uiuc.edu Cc: alereimondo@sugarweb.com 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.
-Ralph
Well FWIW, I think that using "value" for actions is wrong. The value of an object should be the object itself except for things which are "evaluateable" like Blocks. This is like LISP, things evaluate to themselves, or the logical meaning of the value of the object. The value of an object is NOT to take an action. Doing an action is a completely separate thing from finding the value of an object. I think that both overloading "value" and "evaluate" are hacks and that you should use a name like "doAction".
--- james mccartney james@clyde.as.utexas.edu james@lcsaudio.com If you have a PowerMac check out SuperCollider, a real time synth program: http://www.audiosynth.com
squeak-dev@lists.squeakfoundation.org