[squeak-dev] collect:thenDo: woes

Marcel Taeumel marcel.taeumel at hpi.de
Wed Sep 11 14:08:17 UTC 2019


Hi, all.


Let me try to extract the arguments for and against Collection >> #collect:thenDo: (and similar).

Pro
- works with most kinds of Collection
- in the source code, one less pair of parentheses needed
- same semantics as (... collect: [...]) do: [:ea | ...] ... (because it reads almost the same)
- in the source code, the word "then" supports readability (or reading flow) a bit

Contra
- the current implementation creates an extra collection (-> easy to change)
- no inherent support for #collect:as: to configure the target/intermediate kind (-> maybe irrelevant?)
- having all combinations would blow up the interface: do/collect/select/reject/inject ... collect:thenInject:into:thenReject:thenDo: ... (-> big issue)

I think that changing the implementation of #collect:thenDo: to not behave like the "expanded version" -- (... collect: [...]) do: [:ea | ...]  -- could be quite confusing. Take the following example:

#(1 2 3 4) asSet
   collect: [:num | num  even]
   thenDo: [:isEven | Transcript show: isEven].

I think that this snippet should output "falsetrue" (or "truefalse") but not "falsetruefalsetrue" (or the other combinations). Otherwise it would be sth. like #do:afterCollectEach: ... brrrrr ... Same for a SortedCollection where the sort order depends on (or changes with) the values *after* the collect operation.

After reading Richard's discussion, I do still not understand, when (and how) #collect:thenDo: could be misleading. At least not the way Squeak is implementing it at the moment. It is just syntactic sugar for collect;do. We have plenty of that kind of sugar. :-)

Best,
Marcel
Am 11.09.2019 15:14:26 schrieb Stéphane Rollandin <lecteur at zogotounga.net>:
Guys I don't know where you went, but the rationale for getting rid of
#collect:thenDo: is simply that it is syntactic sugar only (just hiding
two parenthesis), and that it makes it at the same time pretty much
useless and very much misleading depending on the receiver, as per
Richard's discussion.

I am not proposing implementing any new thing, just removing that method.


Stef

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190911/d798ff3a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5239 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190911/d798ff3a/attachment.png>


More information about the Squeak-dev mailing list