Collection Hierarchy is out of date

[LinqLover]

Some issues I noticed so far:

• The following classes are missing, or their superclasses are lacking an ellipsis:
  • WeakKeyToCollectionDictionary
  • RawBitsArray (only since Squeak 6.0; with more than 10 subclasses, this might be relevant)
  • SparseLargeTable and SparseLargeArray (maybe interesting?)
  • Interval subclasses
  • Collection itself needs an ellipsis
• The following classes are positioned incorrectly:
  • RunArray (not an ArrayedCollection)

[LinqLover]

Related questions:

• Should Figure 9.3 (Standard collection protocols) include the "copying" protocol with , aCollection, copyWith: newElement, and copyWithout: oldElement?
• @codeZeilen I just scrolled very briefly to this chapter. Should someone re-read this chapter in-depth to check for all updates?

[codeZeilen]

@LinqLover Yes to the checking the chapter. Standard library protocols should definitely work when we create a new edition. Maybe we could ask Robert to do it, he is quite thorough with these things (on the other hand, might have some more interesting content to write).

copying might be interesting because of ,. The other selectors are not that exciting.

The hierarchy can be genereated with the script before it. Will do at one point. :)

[LinqLover]

@codeZeilen Should we add this to the 6.0 milestone? :)

[codeZeilen]

@LinqLover omg, yes please

[LinqLover]

• The following classes are missing, or their superclasses are lacking an ellipsis:

  • WeakKeyToCollectionDictionary

• false report (everything was right)

• RawBitsArray (only since Squeak 6.0; with more than 10 subclasses, this might be relevant)

• [x] discuss this: do we want this class? it's only for optimizations. we could mention RawBitsArray without subclasses, but not sure whether relevant

  note: i felt the need to mention this class name when revising an existing list of homogenous ArrayedCollection subclasses, so now RawBitsArray is mentioned in the chapter but not in the hierarchy

• SparseLargeTable and SparseLargeArray (maybe interesting?)

• [x] discuss as well: also an optimization only (but we could say that for interval as well)

• Interval subclasses

• optimizations only, not relevant

• Collection itself needs an ellipsis

• no, because we only consider classes from package Collections

• The following classes are positioned incorrectly:

  • RunArray (not an ArrayedCollection)

• [x] ack

[LinqLover]

atm, collection hierarchy has not changed in 6.1alpha

[LinqLover]

Other observations and points for discussion:

• [x] fig 10.1 (hierarchy list) and fig 10.2 (image) overlap (duplication)

• [x] "The full list is shown in Figure 10.1" is not true because also fig 10.1 is truncated

• [x] parts of the chapter have a clear lisp-grounded perspective and I'm not sure whether that is helpful (won't the average programmer be more familiar with Python or Java than with Lisp?) Also, in the previous chapter (Exceptions), we are referring to Java instead.

• [x] how do you think about the term "dynamic array" (as opposed to "literal arrays" such as #(1 2 3))? I don't like it because it might suggest that they could not store arbitrary elements in them (which would be the property of heterogeneity instead). The entire vocables are misleading because they suggest different types of arrays but actually just are different types of constructors. I would prefer rewriting that to "array literal" and X, but what would be a proper antonym here? "brace expression"? (note: also update occurrences of "dynamic" in other chapters)

• [x] quote:

  Often Symbols are used as keys, in which case it is natural to use an IdentityDictionary since a Symbol is guaranteed to be globally unique

  Is this actually a best practice? Personally, I would never do this. It might be marginally faster (one method activation less per comparison) but is more likely to break. Similarly, I would also use an IntegerArray only when performance really matters.

• [x] (just a personal opinion but are sorted collections really worth one page? I have very rarely seen good use cases for them, and they annoyingly anticipate the section on sorting.)

• [x] the book recommends implementing hash using xor: (^ title hash xor: authors hash) bitXor: (^ title hash bitXor: authors hash) (I just fixed the selector in the book). I personally use an array instead ({title. xor} hash) if I have less than 10 elements. Again, a bit slower - my version stresses the GC when looking up hashed collections -, but maybe better to read. Should we change the recommendation?

• [x] should we mention collect: #asString (Symbol>>value:) in this chapter at least once? currently, we already mention Symbol>>#ascending.

[codeZeilen]

@LinqLover

• RawBitsArray: Not in the hierarchy, fine in the text
• SparseLargeTable and SparseLargeArray: Mentioning is fine, but not in the hierarchy
• fig 10.1 (hierarchy list) and fig 10.2 (image) overlap (duplication): image can be removed I think
• "The full list is shown in Figure 10.1" is not true because also fig 10.1 is truncated -> remove
• parts of the chapter have a clear lisp-grounded perspective: not too bad, maybe also add a Python example, but I would keep the Lisp reference
• how do you think about the term "dynamic array" (as opposed to "literal arrays" such as #(1 2 3))? What about just array? While it is only a different constructor it makes quite a difference in how one can use it. I think the problem here is that most languages do not really have literal arrays.
• Is this actually a best practice? It was at least. I think I remember some idiom books to still say so. I think it is mostly mentioned in the paragraph to contrast it to Strings used as keys in IdentityDictionaries
• SortedCollection: Shortening would be fine with me, as they are also discussed in the sorting section. I once used a SortedCollection in a project and I found them quite fascinating when I first learned about them, but in the end, I also do not use them much either...
• the book recommends implementing hash ...: I personally find the bitXor: variant easier to grasp. It is more obvious why this is a suitable hash in comparison to the array solution, which requires some knowledge about how array hashing works.
• should we mention collect: #asString (Symbol>>value:) in this chapter at least once?: yes

[LinqLover]

@codeZeilen Thanks for the feedback! I addressed all points in #179, mind to check again? :)