>> I actually find Object do: extremely handy. It's kind of like the
>> composite pattern. I use it mainly to pass an argument to a
>> selector, where the argument may be either a single argument
>> or a collection of arguments (you don't know which). Whatever
>> the case, you can extract the argument(s) by sending it do:
>> (Are there any other neat ways of achieving this in Smalltalk -
>> ie a method that handles either a leaf or a composite?)
>>
>> Notice that this won't work with in:, since the collection protocol
>> is different. It is useful to have a method that makes an atom
>transparently
>> act like a collection of atoms.
>>
>> I can't remember the justification for wanting to remove do:,
>> something about confusing error messages and difficult debugging.
>
>OK, thanks, that makes a lot of sense.
>
>The reason I asked is that I think I've found a way that is
>somewhere inbetween.
>
>It is based on the idea of forwarding messages to the contents of
>the collection, sort of a maximum protocol dilution, but doing this
>only when the programmer indicates this, thus potentially reducing
>confusion.
>
>So, instead of writing:
>
> #( 1 2 3 4 ) + #(1 2 3 4)
> #( 1 2 3 4 ) + 5
> 5 + #(1 2 3 4)
>
>you write (syntax not final)
>
> #(1 2 3 4) collect + #(1 2 3 4)
> #(1 2 3 4) collect + 5
> 5 collect + #(1 2 3 4)
>
>There are two basic differences:
>
>1. Syntax
>
>The syntax is a little more verbose, but also a little more obvious
>because it is compositional.  That is, I have to learn that by saying
>'collect', I can send any message to all the contents of the
>collection while returning the results, and that this also works for
>single objects.
>
>2. Implementation
>
>The implementation is also compositional because it works by
>forwarding messages while iterating through the collection or
>collections.  This eliminates the need to write structurally
>identical forwarder methods  ( abs:  ^ self collect: [:a | a abs],
>etc... ) and immediately makes *all* object protocol available.
>
>Does this sound like a reasonable trade-off?
>
>Marcel
>

I think we are actually talking different things. Your approach sounds very
much like 'map' in functional programming, where a particular function is
applied
(mapped) to all the elements in a collection. Is that right?
I was thinking more of passing an argument to a method. If the argument is
a single object, you would simply send it arg1 #fire, on the other hand, if
the argument is a collection arg1 #fire will fail. On the other hand, if
single
objects understand do: then arg1 do: [each: each #fire] will work. I dont
see how collect solves this problem? does 5 collect 4 work in your
example??

The other issue regarding tradeoffs is that writing the forwarding messages
only
needs to be done once, while "collect +" must be written on each invocation.
I think it may be cleaner syntactically to use '+', but as you point out,
there
may then be ambiguity...

Peter