(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
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
Hi -
1. There is a Stripe package here:
http://smalltalkhub.com/#!/~pdebruic/Stripe
MCHttpRepository
location: 'http://smalltalkhub.com/mc/pdebruic/Stripe/main'
user: ''
password: ''
You can see how it adapts to Stripe's changing API spec.
2. NeoJSONObject, which is par
Hello all,
Several times in the past couple of years I've found myself attempting to
create objects that incorporate/adapt a given APIs specification -- in
other words, building a mini, pharo based SDK for the given API. These are
always JSON based APIs.
I am not sure what the best practices are
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
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
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
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
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
