Hello Martin,
You are right, but I disagree J.
It started by using #valueWithArguments: more often. I find it very bulky, hard to format nicely and difficult to read. This is because the block is the receiver. As last argument, the world looks brighter, because at the end the block formats better.
Compare:
������������������������������ ^aList asArgumentsIn: [:a :b :c |
������������������������������������������������������������ | x y |
������������������������������������������������������������ x := a send: b with: c.
y := ���multiline block���.
x printString, y]
with:
������������������������������ ^[:a :b :c |
������������������������������������������������������������ | x y |
������������������������������������������������������������ x := a send: b with: c.
y := ���multiline block���.
x printString, y
] valueWithArguments: aList
I see the second pattern used in two subsystems in VW, one also uses #cull���
Maybe I find it more difficult to read the second pattern, because the argument list is very far away from the list it associates with.
I think that I will settle with #asArgumentsIn: and see how it reads in real life.
As a shortcut, I can imagine an operator��� (too bad that VW doesn���t support Unicode for operators���)
Thank you!
Von: Esug-list <esug-list-bounces@lists.esug.org> Im Auftrag von Martin McClure
Gesendet: Sonntag, 29. M��rz 2020 17:50
An: Bruce Badger <bwbadger@gmail.com>; Tim Mackinnon <tim@testit.works>
Cc: esug-list@lists.esug.org Members <esug-list@lists.esug.org>
Betreff: Re: [Esug-list] destructDo:
After thinking about this message some more, it seemed to me that it was easier to come up with a good intention-revealing name if the block were the receiver and the array were the argument. It would be some kind of #valueWithArguments: selector. So I looked to see whether there was already such a thing, and sure enough, in Pharo there is #valueWithPossibleArgs:.
#valueWithPossibleArgs: will accept arrays (and I hope any SequenceableCollection) of any size -- trimming the end off if too large, padding with nils if too short.
On the principle of "if it's easy to come up with a good name, the design is probably pretty good" could this possibly be a better solution?
Regards,
-Martin
On 3/29/20 7:50 AM, Bruce Badger wrote: