Hi,
In Pharo 3 you guys integrated Doru’s CollectionsExtension package, which is
great.
You forgot, however, to integrate the utility method #collectAsSet: I was using
in several places in my code.
It should be simply
^ self collect: aBlock as: Set
Could someone please put this in the
Create a ticket
Propose a slice
Enjoy the process :P
Ben
On 10 Dec 2013, at 14:21, Roberto Minelli roberto.mine...@usi.ch wrote:
Hi,
In Pharo 3 you guys integrated Doru’s CollectionsExtension package, which is
great.
You forgot, however, to integrate the utility method #collectAsSet: I
I don't think it has to be in the image,
After all, you can just replace your calls for #collect:as:
Esteban
On Tue, Dec 10, 2013 at 2:21 PM, Roberto Minelli roberto.mine...@usi.chwrote:
Hi,
In Pharo 3 you guys integrated Doru’s CollectionsExtension package, which
is great.
You
No. Since #flatCollectAsSet: is in the image, #collectAsSet: should be in the
image as well.
And then, since we want clean code #collectAsSet: is cleaner than #collect:as:.
On Dec 10, 2013, at 2:23 PM, Esteban Lorenzano esteba...@gmail.com wrote:
I don't think it has to be in the image,
On 10 Dec 2013, at 14:23, Esteban Lorenzano esteba...@gmail.com wrote:
I don't think it has to be in the image,
After all, you can just replace your calls for #collect:as:
I agree. But either you have both
collectAsSet:
flatCollectAsSet:
or you have none. But now there is only
On 10 Dec 2013, at 14:26, Roberto Minelli roberto.mine...@usi.ch wrote:
No. Since #flatCollectAsSet: is in the image, #collectAsSet: should be in the
image as well.
And then, since we want clean code #collectAsSet: is cleaner than
#collect:as:.
Yes, but this also means that you need to
And then rejectAsSet: selectAsHeap: etc...
A big -1
2013/12/10 Yuriy Tymchuk yuriy.tymc...@me.com
On 10 Dec 2013, at 14:26, Roberto Minelli roberto.mine...@usi.ch wrote:
No. Since #flatCollectAsSet: is in the image, #collectAsSet: should be
in the image as well.
And then, since we
Being consistent does not mean we have to be absolute :)
Ben
On 10 Dec 2013, at 14:38, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com
wrote:
And then rejectAsSet: selectAsHeap: etc...
A big -1
2013/12/10 Yuriy Tymchuk yuriy.tymc...@me.com
On 10 Dec 2013, at 14:26, Roberto Minelli
IMO, if there is an error, then is the presence of #flatCollectAsSet:, not
the absence of the other(s).
Esteban
On Tue, Dec 10, 2013 at 2:38 PM, Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com wrote:
And then rejectAsSet: selectAsHeap: etc...
A big -1
2013/12/10 Yuriy Tymchuk
IMHO having two common usages of #flatCollect:as: and #collect:as: is good.
Then, do whatever you want. In my image I have #collectAsSet:.
On Dec 10, 2013, at 2:40 PM, Esteban Lorenzano esteba...@gmail.com wrote:
IMO, if there is an error, then is the presence of #flatCollectAsSet:, not
the
I think that collectAsSet: is used a lot because we convert collection and
remove duplicates. So it won’t be the same with select: . But I prefer to use
#removeDuplicates, because this explicitly says: I want to remove duplicates,
and not use a side effects of Set. Anyway have a nice day guys,
A fact is that there are way too many methods in (Sequenceable)Collection
already, with duplicated implementations/features.
So if collect:as: does the job why the hell add yet another selector?
2013/12/10 Roberto Minelli roberto.mine...@usi.ch
IMHO having two common usages of #flatCollect:as:
On 10 December 2013 14:47, Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com wrote:
A fact is that there are way too many methods in (Sequenceable)Collection
already, with duplicated implementations/features.
So if collect:as: does the job why the hell add yet another selector?
+1
So if self do: [:each | tally := tally + 1] computes the size of a
collection, why do we need the #size selector?
On Dec 10, 2013, at 3:08 PM, Igor Stasenko siguc...@gmail.com wrote:
So if collect:as: does the job why the hell add yet another selector?
Do I really need to respond to this? Well you're lucky, my child not yet
awoke:
1) size is often implemented O(1) above is O(n)
2) typing size is very short compared to open code you provided
3) size has many senders which makes it worth
4) size is part of ANSI
Which of these points apply to
On Dec 10, 2013, at 4:19 PM, Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com wrote:
Do I really need to respond to this?
No.
Well you're lucky, my child not yet awoke:
Is this a threat? :lol:
1) size is often implemented O(1) above is O(n)
2) typing size is very short compared to
A threat? You're completely miss-understanding me, it just that it gave me
some time to answer you.
As long as it's your images, you're free man, implement whatever you like.
Weren't we speaking of incorporating some messages in trunk development?
Then you have to deal with other's opinion. Mine
On Dec 10, 2013, at 5:09 PM, Nicolas Cellier
nicolas.cellier.aka.n...@gmail.com wrote:
A threat? You're completely miss-understanding me,
I was kidding ;)
it just that it gave me some time to answer you.
As long as it's your images, you're free man, implement whatever you like.
Weren't we
At the end, anyway, Steph and Marcus decide.
No :)
We decide. So YOUR point of views are important because we can be in a bad mood
not smart enough or whatever :).
Now at the end of this discussion I have the impression that having
collect:as: and flatCollect:as: would be good and
19 matches
Mail list logo
