[Jtsummers]

> Every wrapper is a thing itself which must also be understood when trying to understand how things work.

I'd offer a different view. Wrapping/abstracting like this should reduce the amount of things a user of the abstraction needs to know. I don't care how Java's BigInteger class works under the hood, only that it does what I need it to do. If I did have to know how it worked to use it, this suggests a failure on the part of whoever created it.

It does increase what the maintainer of the underlying system (including the abstraction) needs to know, but if done in a sane manner this should not be a burden. So we're making a tradeoff. The user gets something simpler, the underlying system maintainer gets something a bit more complex. Or the user gets something more complex and with more boilerplate but the underlying system maintainer gets something simpler (though will be pestered with, "Why don't you offer a generic set yet?" asked for years to come).

> meaning if you have changes which impact multiple layers of wrap, its harder to determine what to change, and to maintain the understandability of each layer.

When this happens, in my experience, it has meant one or more of:

1. The choice of how to wrap/abstract was poorly chosen

2. The choice was made too early (before the problem was properly understood)

3. A major change was made that would've been hard to identify/plan for earlier

I ignore (3) when writing code beyond what's reasonable to plan for. (1) and (2) though mean I mostly agree with this:

> Create an abstraction at the last moment

But rephrased, borrowing the phrase I first saw in some Lean Software book, "last responsible moment." It's not sensible, for instance, to use a map to booleans as a set throughout the project's life and only wrap it at the last moment. If you know it's going to be a set, wrap it early because this offers clarity to your code and reduces boilerplate/noise. If you know you need a stack, and have a vector available, wrap it and hide the random access option. If it later turns out that you also want random access, you can offer it, but if it's been available from the start then users will have abused that and you won't be able to rein it in later (without a lot of effort and heartache).

[philosopher1234]

I'm not sure how I feel about the `set` wrapper. I suppose its nice to hide some of the detail of how the set works. On the other hand, it is confidence inspiring to be told "this is just a map, its really that simple" as a user. I have a similar conflict about string alias types like `type MyId string`.

[RHSeeger]

But it's not a Map, it's a Set. If I see an API return a Map, I expect it's returning a relationship of keys to values, because that's what a Map is used for. If I see it returning a Set, I expect it's return a collection of unique values, because that's what a Set is used for.

I mean, you could support only List objects in the language and call it a day because they can be used as anything else. Or only lambdas, for the same reason. At the end of the day, though, having structures for the various ways you want to treat data is helpful. Using the right structure to hold data reduces cognitive load.