[BUG][FIX] WeakSetCollectFix-nk
Richard A. O'Keefe
ok at cs.otago.ac.nz
Tue Mar 12 23:34:15 UTC 2002
"Ned Konz" <ned at bike-nomad.com>
provided a correction to WeakSet>>collect:
The problem is that Set does
newSet := Set new: self size.
array do: [:each | each ifNotNil: [newSet add: (aBlock value: each)]].
^newSet
instead of using the inherited Collection method
newCollection := self species new.
self do: [:each | newCollection add: aBlock value: each)].
^newCollection
Now the funny thing is that the Collection>>collect: method
- would give the right result for WeakSet
- but this is NOT a case for super super, because it would ALSO
give the right result for Set.
so perhaps the simplest fix of all would simply be to delete the
Set>>collect: method (which may, after all, over-allocate).
It's high time Sets had a redesign anyway. The nil object has
perfectly workable #= and #hash methods, so why _can't_ it be an
element of a Set? It makes perfect sense.
For example, Set could have a Dummy class variable, lazily initialised
to be (for example) Object new, and that could be used instead of nil.
Squeak 3.0 of 4 February 2001, latest update: #3552,
running on a 266MHz PowerMac G3 with MacOS 8.6 and 64MB of memory.
|a|
[a := Set new. 1 to: 1200 do: [:i | a add: i]] timeToRun
==> 39
"with the same setup"
[a collect: [:each | each]] timeToRun
==> 24
"with Set>>collect: removed"
[a collect: [:each | each]] timeToRun
==> 45
so that's a fairly strong argument for retaining the code in Set.
Or would be, except that
[a select: [:each | true]] timeToRun
==> 44
If we can tolerate that time from #select:, we can tolerate it from
#collect:, no?
More information about the Squeak-dev
mailing list
|