Daniel Vainsencher danielv@netvision.net.il wrote: I wonder if #union: of Bags should use Set semantics or Bag semantics. This has been discussed before. In fact, I recall raising the issue myself quite some time ago.
Currently, and with your suggestion - #(1 2 1) asBag union: #(1 2) asBag -> a Set(1 2) which is precisely what it is documented as doing. I would personally _prefer_ it to return a Bag, but I can't call it a bug when a method delivers the result its documentation says it delivers, without any nasty side effects.
It would be more meaningful, and one can always convert to Sets first to get the usual functionality. Well, you can always write
(aCollection copy asBag) addAll: anotherCollection; yourself
if you want bag union. Or even
(aCollection asArray , anotherCollection asArray) asBag
More importantly, if #union: were changed in this way, #intersection: and #difference: should also be changed.
To be really honest, I think #union:, #intersection:, and #difference: belong in Set (and its subclasses), not Collection. How often do you want to compute the union of a Dictionary and a SortedCollection?
But what Bag>>union: does and whether #union: should be in Collection at all are design issues that deserve wider debate and probably can't be changed without breaking someone's code. We don't have to settle such matters before fixing an obvious bug.
"Richard A. O'Keefe" ok@cs.otago.ac.nz wrote:
But what Bag>>union: does and whether #union: should be in Collection at all are design issues that deserve wider debate and probably can't be changed without breaking someone's code. We don't have to settle such matters before fixing an obvious bug.
Another solution is to move #, higher in the collection hierarchy. In fact, you wouldn't even need #union: any longer.
-Lex
squeak-dev@lists.squeakfoundation.org