2010/5/3 St�phane Ducasse�<stephane.ducasse@inria.fr>
> Hi, this is my first post (please be gentle xD)

Thanks!

xD

>
> The #collect: message commonly return a new collection like the receiver, but this is really unpractical in some cases
>
> e.g.
> col := Set with: 'one'->1 with: 'two'->2 with: 'dos'->2.
> (col collect: [:each | each value ]) sum

In VW you get the same.

Yes

> In this example #sum will return 3 instead of 5 (I searched a test for #sum but I didn�t find it).
>
> Ok, I can use the message #asBag (or something like that) but does the second line have to depend on the type of the receiver (i.e. the type of col)?

I think that this is the invariant for collect: ?

I didn�t understand that.�
I'll like that this line�(col collect: [:each | each value ]) sum
always returns 5 independently of the class of�col�(if�col�has the elements�'one'->1�,�'two'->2�and�'dos'->2).

> For example, the implementation of #collect: in SortedCollection returns an OrderedCollection (in the current image)

in VW too

Yes, I like that.�I just put the example to show that�#collect:�not always returns a new collection like the receiver.�

> and in other dialects the message #collect: when the receiver is a Set returns a Bag ...

which ones?


In IBM VisualAge 6.0 returns a Bag (in Instantiations�VA�7.5.2 returns a Set).

> Basically, what do you think of an implementation like this?
>
> Set >> collect: aBlock
> �"Evaluate aBlock with each of the receiver's elements as the argument.
> �Collect the resulting values into a Bag. Answer the new collection."
> �| newBag |
> �newBag := Bag new: self size.
> �array do: [:each | each ifNotNil: [newBag add: (aBlock value: each)]].
> �^ newBag

2010/5/4 Nicolas Cellier�<nicolas.cellier.aka.nice@gmail.com>
True.It can be impractical, but no need to change #collect:
Please use #detectSum:

(Set with: 'one'->1 with: 'two'->2 with: 'dos'->2) detectSum: [:e |e value].
or #collect:as:

((Set with: 'one'->1 with: 'two'->2 with: 'dos'->2) collect: [:e |e
value] as: Array) sum.

Nicolas

Nice =) I didn't know those messages (although IMHO the name #detectSum: is not pretty - I'm thinking aloud here ... #acummulateSum: or: directly #sum: ...?)

The reason I'm proposing to change the Set >> #collect: implementation is because the only situtation when you need that #collect: returns a Set is when you didn't want duplications and for that is really nice to explicity send the message asSet.

In all other cases a Bag is all you need as response to collect (when collect is sended to a Set).

If you say this is counterproductive and the change will generate more headaches than happiness I understand xD

Cheers,



2010/5/3 Germ�n Leiva <leivagerman@gmail.com>:
> Hi, this is my first post (please be gentle xD)
>
> The #collect: message commonly return a new collection�like the receiver,
> but this is really unpractical in some cases
> e.g.
> col := Set with: 'one'->1 with: 'two'->2 with: 'dos'->2.
> (col collect: [:each | each value ]) sum
> In this example #sum will return 3 instead of 5 (I searched a test for #sum
> but I didn�t find it).
>
> Ok, I can use the message #asBag (or something like that) but does the
> second line have to depend on the type of the�receiver (i.e. the type of
> col)?
> For example, the implementation of #collect: in SortedCollection returns an
> OrderedCollection (in the current image) and in other dialects the message
> #collect: when the receiver is a Set returns a Bag ...
>
> Basically, what do you think of an implementation like this?
>
> Set >> collect: aBlock
> �"Evaluate aBlock with each of the receiver's elements as the argument.
> �Collect the resulting values into a Bag. Answer�the new collection."
> �| newBag |
> �newBag := Bag new: self size.
> �array do: [:each | each ifNotNil: [newBag add: (aBlock value: each)]].
> �^ newBag
> Cordially,
> --
> Germ�n Leiva
> LeivaGerman@gmail.com
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
Germ�n Leiva
LeivaGerman@gmail.com