>It sounds like a reasonable change to me, so I'd recommend submitting an
>[FIX]/[ENH] change.

I'll put one together.  It looks like I have found at least one more bug while
working on my project last night.  Set needs to override #shallowCopy because
the default implementation in Object>>shallowCopy is not suitable for Sets. 
Object>>shallowCopy causes their 'array' variable to be shared, when in fact,
they should just be sharing the objects IN those array variables.

For example, here we see the Set referred to by 'b' is left in an inconsistent
state after being shallowCopied from a:

| a b |
a _ Set new
	addAll: Morph subclasses;
	yourself.
b _ a shallowCopy.
a removeAll: a copy.
b

b cannot even generate its own printString correctly.  Further exploration of b
reveals its enumeration behavior is not consistent with its reported size.

At first, I was tempted to think that it was "correct" because people should be
using copy anyway.  But Squeak needs to provide persistence frameworks, that
typically *need* truly shallow copies of objects and cannot rely on copy
because application domains override for their needs, consistent behavior among
these "lower-level" methods.  In this case, Set>>shallowCopy needs to behave
universally the same, which is to give you a useful copy of the top-most object
that *semantically* references the same objects its source did.

Something like this:

  Set>>shallowCopy
    | copy |
    copy _ self species new: self size.
    self do: [ :each | answer add: each ].
    ^copy

I'm may run across more examples among the other hashed collections within the
next few days (it looks like someone already took care of
SequenceableCollection).  If I find more examples, I'll fix them all into one
changeSet and submit it to *everyone* (not just the harvesters :-D  ) for
review.


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com