Hello!
(#(1 2 3) asSet collect: #odd)
do: [ :each | Transcript show: each; cr ]
> true
> false
#(1 2 3) asSet collect: #odd
thenDo: [ :each | Transcript show: each; cr ]
> true
> false
> true
Bug or feature?
Herby
Feature!
collect: forms a new collection of the same kind as its receiver. In this
case a set. As the result of your collect:
#(1 2 3) asSet collect: #odd)
is booleans, the resulting set will contain only to elements (the duplicate
odd resulting in true is removed).
collect: thenDo: applies the c
Surprise!
The selector #collect:thenDo: strongly suggests that it behaves just as
#collect: then #do:. But as #collect: usually means map + aggregate in the
reveiver type, I'd expect the input to the do block to be deduped already. At
least it is an easy to miss source of subtle bugs. Maybe an
I don't know the correct answer, but I am skeptical of one that relies on a
specific implementation rather than a specific definition.
I would like to see and understand the arguments for one interpretation
versus another.
Prima facie, the expectation that set behaviour propagates through the
imp
The first version:
(#(1 2 3) asSet collect: #odd)
do: [ :each | Transcript show: each; cr ]
is rather straight forward I believe, as collect: and do: has been around
forever (relatively speaking).
#(1 2 3) asSet collect: #odd
thenDo: [ :each | Transcript show: each; cr ]
On 8 September 2019 a
Two comments:
First, the method comment for Collection>>collect:thenDo: is "Utility method
to improve readability", which is exactly the same as for
collect:thenSelect: and collect:thenReject:. This suggests that the
*intention* of the method is not to introduce new behaviour, but simply to
provide
On 8. 9. 2019 14:28, Peter Kenny wrote:
Two comments:
First, the method comment for Collection>>collect:thenDo: is "Utility method
to improve readability", which is exactly the same as for
collect:thenSelect: and collect:thenReject:. This suggests that the
*intention* of the method is not to intr
The difference in behaviour is exactly what I would expect.
I can't think of any way to make
aSet collect: collectBlock thenDo: doBlock
act identically to
(aSet collect: collectBlock) do: doBlock
without creating an intermediate set.
Here, for example, is the definition in Smalltalk/X,
with commen
(1) If you want (aSet collect: collectBlock) do: doBlock
you can write exactly that. Nothing stops you, and it will
be as clear and reliable as any use of Set>>collect:, which
is to say NOT VERY CLEAR OR RELIABLE AT ALL.
(2) #collect:then{Do:Select:Reject:} had no other purpose than
On Mon, Sep 09, 2019 at 05:46:48PM +1200, Richard O'Keefe wrote:
>
> (3) Oddly enough, the reason that #collect:thenDo: exists in my
> library is that I copied it from Squeak, at a time when it had
> the same definition as Pharo and ST/X. Had I known of the change
> in Squeak I would
I think this thread indicates that the selector #collect:thenDo: may
indeed cause some missunderstanding given standard semantics of #collect:.
Is there any reason not to use a different one, such as #map:thenDo:, to
make the difference clearer?
A nice side effect could be a new automatic refacto
Digging a bit further, the change from the pointless implementation to
the current implementation was made between Pharo 2.0 and Pharo 3.0
and the current definition was introduced into ST/X some time between
2010 and 2012, which is about the same time as Pharo.
{collect,select,reject}:thenDo: were
An automatic refactoring rule that converts
(a collect: b) do: c
to
(a collect: b thenDo: c)
would change the semantics of the code in all of
Squeak, Pharo, and Smalltalk/X, whichever definition
of #collect:thenDo: is taken, and in Squeak would
make the code slower, not faster.
Using a differe
13 matches
Mail list logo
