Hi Eliiot.

I am not a native English - but collect: means collect IMO.

so for every element deliver the result of evaluating the block. DOT

interesting issue.

Frank

  _____  

Von: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] Im Auftrag von Eliot
Miranda
Gesendet: Mittwoch, 26. November 2014 23:44
An: The general-purpose Squeak developers list
Betreff: ** SPAM ** Re: [squeak-dev] IdentitySet>>collect:

 

 

 

On Wed, Nov 26, 2014 at 2:37 PM, Frank Lesser
<frank-lesser at lesser-software.com> wrote:

hmm, the problem is different IMO,

 

**corrected, but still wrong**

(IdentitySet withAll: #(1 1.0)) collect: [:e| e asInteger ]   IdentitySet(1
)

 

collect: should always preserve the size of the original collection so it
must return an OrderedCollection !

 

Since when?  I'm not sure I accept that collect: is one-to-one.  For Sets I
wouldn't expect that.

 


  _____  


Von: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] Im Auftrag von Eliot
Miranda
Gesendet: Mittwoch, 26. November 2014 22:57
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] IdentitySet>>collect:

 

 

 

On Wed, Nov 26, 2014 at 1:26 PM, Levente Uzonyi <leves at elte.hu> wrote:

On Wed, 26 Nov 2014, David T. Lewis wrote:

On Wed, Nov 26, 2014 at 08:01:49PM +0100, Levente Uzonyi wrote:

On Wed, 26 Nov 2014, Eliot Miranda wrote:

Hi All,
? ? IdentitySet>>collect: answers a Set, not an IdentitySet.? Anyone else
agree this is a serious bug?? Anyone else disagree?

WTF??

(IdentitySet withAll: #(1 2 3 1.0 2.0 3.0)) collect: [:e| e] a Set(1.0 2 3)
--
best,Eliot


Sometimes it's feasable to return an IdentitySet, other times it's not, so
there's no optimal solution - #collect: can't cover all cases.

Set >> #collect: explicitly returns a Set, because this is the least bad
solution to handle all of its subclasses reasonably well.
In case of WeakSet, returning a WeakSet makes no sense, because some of
your objects will disappear immediately.
In case of IdentitySet, PluggableSet, KeyedSet and KeyedIdentitySet the
returned values may not behave well in the original collection.

The best is to always be explicit:

(IdentitySet withAll: #(1 2 3 1.0 2.0 3.0)) collect: [ :e | e ] as:
IdentitySet
"==> an IdentitySet(1 2 3 1.0 2.0 3.0)"

Levente


In Squeak 2.8 (checked on http://bertfreudenberg.github.io/SqueakJS/run/):

 (IdentitySet withAll: #(1 2 3 1.0 2.0 3.0)) collect: [:e| e] ==> a Set(2.0
1 2 3 3.0 1.0)


But in trunk I get this:

 (IdentitySet withAll: #(1 2 3 1.0 2.0 3.0)) collect: [:e| e] ==> a Set(1 2
3)


So answering a Set makes sense for the reasons that Levente explains, but
trunk
is definitely broken WRT the contents of that set.

This bug needs a unit test to go along with whatever fix we agree on.

 

It's not a bug either. The Floats are not there, because they are equal to
the integers:

1 = 1.0 "==> true"
1.0 = 1 "==> true"

Therefore they have the same hash:

1 hash "==> 1"
1.0 hash "==> 1"

The bug was in Squeak 2.8:
1.0 = 1 "==> true"
1 = 1.0 "==> true"
1 hash "==> 1"
1.0 hash "==> 61440"

Here's the comment of Float >> hash from The Trunk:
        "Hash is reimplemented because = is implemented. Both words of the
float are used. (The bitShift:'s ensure that the intermediate results do not
become a large integer.) Care is taken to answer same hash as an equal
Integer."

 

Exactly.

 

My hope would be something like this (Set order is arbitrary)

 

        ((IdentitySet withAll: #(1 2 3 1.0 2.0 3.0)) collect: [:e| e]) =>
IdentitySet (1 2 3 1.0 2.0 3.0)

 

but that

       (Set withAll: #(1 2 3 1.0 2.0 3.0)) => Set (1 2 3)

 

(and it always contains just the integers since these are added first).

 

But Levente's collect:as: solution is perfectly acceptable and as he points
out has the advantage of being explicit.

 


Levente


Dave



 





 

-- 

best,

Eliot









 

-- 

best,

Eliot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141126/11366fe0/attachment.htm