[BUG] Set>>collect:
Richard A. O'Keefe
ok at cs.otago.ac.nz
Tue Feb 18 02:36:03 UTC 2003
You have new collection classes? Richard! Why haven't you
posted them on SqueakMap?! :-)
Because I wrote them as an exercise in understanding the ANSI Smalltalk
standard. They are deliberately slightly weird. For example, whenever
ANSI Smalltalk _allows_ a result to be a read-only sequence, I actually
return a read-only sequence. So I have
Object
ListNode (used in Sets)
AssociationListNode (used in Dictionaries)
Collection
Dictionary
IdentityDictionary
PluggableDictionary
Set
IdentitySet
PluggableSet
Bag
IdentityBag
PluggableBag
SequenceReadableCollection
Interval
DateInterval (an interval of Dates, what else?)
ReadOnlyArray
Array
ReadOnlyByteArray
ByteArray
ReadOnlyString (an array of UTF-16 codes)
Symbol
String (adds mutation)
SequencedContractibleCollection
OrderedCollection
SortedCollection (note: DOESN'T inherit from OrderedCollection)
Things Squeak has that are missing:
SequenceableCollection (basically SequenceReadableCollection)
ArrayedCollection
Heap (I mean to put this in some time)
LinkedList
MappedCollection
SharedQueue
Text
{Color,Float,Integer,Word}Array
WordArrayForSegment
RunArray
Array2D
SkipList and friends
Weak{Array,IdentityKeyDictionary,KeyDictionary,Registry,Set,
ValueDictionary}
Also, because this was an exercise in understanding the ANSI standard,
whenever the ANSI standard leaves a result unspecified, there isn't any
interesting result. This is quite likely to break existing Squeak code.
And of course, I was trying to understand the ANSI standard, so a lot of
the Squeak methods just aren't there, mainly the standard ones, ones I
needed to implement the standard ones, and ones I couldn't resist.
Bringing this into closer conformity to Squeak would be a LOT of work.
One problem that it's hard to replace _any_ collections without replacing
_all_ collections.
Right now, for example, with #collect:into:, there are a lot of questions
that need answering. Should WeakSet>>collect: answer a Set or a WeakSet?
Just because we don't want to hold onto the elements we started with, that
doesn't mean we don't want to hold onto the results! I'm inclined to make
it a Set, but could that break anything? Ditto for WeakArray.
If WeakSet>>collect: and WeakArray>>collect: return weak containers,
why do Weak*Dictionary>>collect: return plain OrderedCollections?
Why does WeakSet>>>collect: answer a WeakSet, but WeakRegistry>>collect:
answer a plain Set? It looks to me as if all the Weak* things should
answer plain collections, not weak collections. But would that break
anything?
Buglet:
WeakRegistry>>printElementsOn: aStream
has
ifNotNil: [aStream nextPutAll: '<this WeakRegistry is locked>; space'].
which should read
ifNotNil: [aStream nextPutAll: '<this WeakRegistry is locked> '].
Building an ANSI-complete set of collection classes was extremely
instructive. One thing it taught me was that I really want Traits.
I am unhappy about the amount of code that had to be copied.
More information about the Squeak-dev
mailing list
|