[squeak-dev] The Inbox: Collections-mt.961.mcz

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Wed Oct 27 14:01:58 UTC 2021

Hi Marcel,

thank you for the examples. :-)

I only wanted to note that #in: is not an uncritized idiom, but personally, I am not a general opponent to it.

When I use #in:, I mostly do this to keep cascades intact like in your #addMorph: example.

However, this situation usually would not apply to your collection example. In this case, as far as I can see, the very only purpose of #allIn: would be to add another scope inside a method.

As already mentioned in some other discussion about #in:, I see the latter pattern as a temporary helper construct which in most cases should be the preliminary stage of an "extract method" refactoring for the block passed to #in:.

That being said, I am not against a new convenience selector that does not harm in any way. :-) I am only wondering whether adding a new selector like this means that it would be okay to use it for Inbox/Trunk submissions or whether the list of the acceptable/considered-good-style protocols is a true subset of all protocols that we provide in the Trunk.



Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 27. Oktober 2021 15:50:01
An: squeak-dev
Betreff: Re: [squeak-dev] The Inbox: Collections-mt.961.mcz

Hi all --

If you don't like to use #in:, this is probably not for you.

However, if you occasionally use #in: to tweak longer cascades or to avoid a method-local temps in favor of block-scopes, #allIn: expands #in: to multiple variables.

#in: and #allIn: would allow you to work with an extra scope (and names) to clarify your code as needed. It's not without alternatives. Regular temps can do everything that #in: can do.

| instance |
instance := Morph new.
self addMorph: instance.
^ instance


^ Morph new
   in: [:instance | self addMorph: instance];

It's not that important. :-) The second style makes it easier to be commented-out in its entirety, for example.

Here is another example for using fresh bindings:

{ SomePreferenceObject . PreferenceObject new } allIn: [:old :new |
   SomePreferenceObject := new].

#allIn: seems not too important since it can easily be simulated with #in:. Not sure. Probably needs more use cases. During the past years, I only found very few situations where I would prefer #in: over extra temps. I one case, my goal was a one-liner to make the text-diff look more compact. =)


Am 27.10.2021 14:51:42 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:

Hi Marcel, could you maybe share some practical examples for #allIn:? I know that many people dislike #in:, too, as it can be used as just another dubious dispatch ...



Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von commits at source.squeak.org <commits at source.squeak.org>
Gesendet: Mittwoch, 27. Oktober 2021 13:27:06
An: squeak-dev at lists.squeakfoundation.org
Betreff: [squeak-dev] The Inbox: Collections-mt.961.mcz

A new version of Collections was added to project The Inbox:

==================== Summary ====================

Name: Collections-mt.961
Author: mt
Time: 27 October 2021, 1:27:04.102238 pm
UUID: ff529f7f-b6c8-da48-91cf-201db580c537
Ancestors: Collections-eem.960

Propose addition of #allIn:. See comment. Please review and discuss.

=============== Diff against Collections-eem.960 ===============

Item was added:
+ ----- Method: Array>>allIn: (in category 'accessing') -----
+ allIn: aBlock
+        "Use the receivers contents as arguments for aBlock. Truncate not needed arguments, fill in missing ones with nil. Similar to #groupsDo: for single block invocation. Use it to avoid nested calls of #in:.
+        Note that this is implemented here in Array to allow its use only in literal arrays."
+        ^ aBlock valueWithEnoughArguments: self!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211027/c8f698ea/attachment.html>

More information about the Squeak-dev mailing list