At 9:49 PM 8/25/98, Travis Griggs wrote:
>Maurice Rabb wrote:
>
>> <snip>
>> For this to work would require that I add Object>>#value which I remember
>> is a no-no, because it dilutes the BlockContext protocol as Object>>#do:
>> diluted the Collection protocol.  We replaced Object>>#do: with #in:, so
>> with what do we replace Object>>#value?
>> <snip>
>
>Just out of curiousity and because it's late and I'm in a devil's advocate
>mood... What's wrong with diluting  protocols? I have vaguely seen threads
>about this, but I've never really seen (or paid attention long enough), a good
>reason not to dilute protocols. It's just kind of one of those unexplained
>commandments (too me). I have personally thought many times that it would be
>cool to totally blur the lines between collections and single objects in
>Smalltalk for quite some time. Isn't that one of the things Lisp kind of does?
>Why does enumeration have to be bound to a storage strategy?

Travis--

Well lets review what the wise ones have said:


At 7:46 AM 5/29/98, Ralph E. Johnson wrote  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!)
>

At 4:08 PM 5/29/98, Andreas Raab continued:
>> 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.
>
>I absolutely agree. One thing I don't like at the moment is that Object
>implements #do: It's easy enough to define either asCollection or to
>implement #do: in classes where this is really needed.
>
>> (I'm hoping that if I say it enough, people will believe me!)
>
>I do ;-)
>
>  Andreas

Turning to the "Way Back Machine" even further back, a _very_ wise
Smalltalker wrote  Re: Proposal: Object>>valueIn:

At 2:44 PM 11/3/97, Travis Griggs wrote:
>Ah yes, you are right. Having now thought about it, I think they should
>both exist. They accomplish different things semantically. I still like the
>presence of do: in Object for the purpose of "iterating" over single
>objects as if they were indeed aggregations.
>
>--

If you think about it you could argue that this is the same argument as
#valueIn: (i.e. #in: as it is now) vs. #do:  The semantics of a Collection
iterating over itself, and 0-1-Many iterating over itself _as_ a Collection
are subtly different enough to make a separate protocol a "safe" ideal.  In
practice, the gurus say that it tends to hide normal Collection use errors.
Likewise, the potential of not catching error of using any old Object
instead of an intended BlockContext.

Personally Travis, I waffle back and forth toward your position.  There is
a simple elegance in a unilateral #do: and a unilateral #value.

--Maurice

---------------------------------------------------------------------------
  Maurice Rabb    773.281.6003    Stono Technologies, LLC    Chicago, USA