On Fri, Nov 28, 2014 at 4:26 PM, Sven Van Caekenberghe sven@stfx.eu wrote:
On 28 Nov 2014, at 15:35, Marcus Denker marcus.denker@inria.fr wrote:
On 27 Nov 2014, at 08:21, Marcus Denker marcus.denker@inria.fr wrote:
On 26 Nov 2014, at 19:19, Eliot Miranda eliot.miranda@gmail.com
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)
Yes, I would say so. I think we fixed some others like that already
(not 100% sure)
I added an issue tracker entry
14535 IdentitySet>>collect: answers a Set, not an IdentitySet. https://pharo.fogbugz.com/f/cases/14535
#collect: directly uses Set in Set>>#collect, I committed a fix (to the
issue tracker, to be reviewed)
to use “self species” instead (plus the example from above as a test in
IdentitySetTest).
MarcusI think that is the most logical thing to do, it is what I would expect.
I know others have cases where that is not really what you want (some of Set's subclasses are pretty special), but it is still a good default, while #collect:as: can be used for all other cases (and subclasses can override #species again if they want).
Hmm... errors found by the test runner on that change.
https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/17683//artifact/vali...
So we will need to check...
Marcus
2014-11-28 16:39 GMT+01:00 Marcus Denker marcus.denker@inria.fr:
On Fri, Nov 28, 2014 at 4:26 PM, Sven Van Caekenberghe sven@stfx.eu wrote:
On 28 Nov 2014, at 15:35, Marcus Denker marcus.denker@inria.fr wrote:
On 27 Nov 2014, at 08:21, Marcus Denker marcus.denker@inria.fr
wrote:
On 26 Nov 2014, at 19:19, Eliot Miranda eliot.miranda@gmail.com
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)
Yes, I would say so. I think we fixed some others like that already
(not 100% sure)
I added an issue tracker entry
14535 IdentitySet>>collect: answers a Set, not an IdentitySet. https://pharo.fogbugz.com/f/cases/14535
#collect: directly uses Set in Set>>#collect, I committed a fix (to the
issue tracker, to be reviewed)
to use “self species” instead (plus the example from above as a test in
IdentitySetTest).
MarcusI think that is the most logical thing to do, it is what I would expect.
I know others have cases where that is not really what you want (some of Set's subclasses are pretty special), but it is still a good default, while #collect:as: can be used for all other cases (and subclasses can override #species again if they want).
Hmm... errors found by the test runner on that change.
https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/17683//artifact/vali...
So we will need to check...
Marcus
In pharo, the problem is the OCKeyedSet, but the same happens in squeak with a KeyedSet. Changing Set>>#collect: to use "self species new" the following code fails:
k:=KeyedSet new keyBlock:[:e | e name]. k addAll:{ Color red . Color blue . Color green}. k collect:[:e | e ]. --> MessageNotUnderstood: Color>>key
Hi Nicolai,
On Nov 28, 2014, at 4:01 PM, Nicolai Hess nicolaihess@web.de wrote:
2014-11-28 16:39 GMT+01:00 Marcus Denker marcus.denker@inria.fr:
On Fri, Nov 28, 2014 at 4:26 PM, Sven Van Caekenberghe sven@stfx.eu wrote:
On 28 Nov 2014, at 15:35, Marcus Denker marcus.denker@inria.fr wrote:
On 27 Nov 2014, at 08:21, Marcus Denker marcus.denker@inria.fr wrote:
On 26 Nov 2014, at 19:19, Eliot Miranda eliot.miranda@gmail.com 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)
Yes, I would say so. I think we fixed some others like that already (not 100% sure)
I added an issue tracker entry
14535 IdentitySet>>collect: answers a Set, not an IdentitySet. https://pharo.fogbugz.com/f/cases/14535
#collect: directly uses Set in Set>>#collect, I committed a fix (to the issue tracker, to be reviewed) to use “self species” instead (plus the example from above as a test in IdentitySetTest).
MarcusI think that is the most logical thing to do, it is what I would expect.
I know others have cases where that is not really what you want (some of Set's subclasses are pretty special), but it is still a good default, while #collect:as: can be used for all other cases (and subclasses can override #species again if they want).
Hmm... errors found by the test runner on that change.
https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/17683//artifact/vali...
So we will need to check...
MarcusIn pharo, the problem is the OCKeyedSet, but the same happens in squeak with a KeyedSet. Changing Set>>#collect: to use "self species new" the following code fails:
k:=KeyedSet new keyBlock:[:e | e name]. k addAll:{ Color red . Color blue . Color green}. k collect:[:e | e ]. --> MessageNotUnderstood: Color>>key
And if you implement species in KeyedSet to answer Set (which should fix this one issue) does anything else break?
Eliot (phone)
squeak-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Marcus Denker -
Nicolai Hess