Q: About adding "Collections" package dependency: an extra screen with checkboxes and "Finish" button

This screen pop up. I've not seen this screen before. What different about "Collections"?

What should I select here? If I want everything, is selecting only "Collections" enough?

I'm pretty sure the "DequeModule" is Deque, is the "OrderedCollections" for both OrderedSet and OrderedDictionary?

What should I select if I want to get everything, including any new additional to this package?

Collections includes both, so that what you're after. The others (I suspect) are there if you only want to pull in a subsection of collections - either the ordered sets or deque.

2 Likes

"DequeModule" and "OrderedCollections" names kind of inconsistent. Maybe they should be:

"Deque" and "OrderedCollections"
or
"DequeModule" and "OrderedCollectionsModule"

?

The trailing word “module” is redundant and normally poor style.

DequeModule would have been just named Deque, except that a type in the same module already has that name. This trips a compiler bug, making it impossible to disambiguate what module it should be drawn from. i.e:

var x: Deque.Deque? = nil // Would not compile.
var y: DequeModule.Deque? = nil // ✓ Viable.
var z: Deque.DequeType? = nil // ✓ Viable.

In these cases adding the annoying disambiguating text to the module instead of the type is better, because the module will be referenced far less often than the type. So the form SomeModule is a widely used and recognizable workaround, but only for modules that have this problem.

There is no type named “OrderedCollections”, so that module doesn’t need it.

6 Likes

:+1::pray:

To answer this, Collections has more than one product, which is why you see this UI. If the package contained only a single product this UI would be redundant.

3 Likes