"Pool" suggests anonymity: "secretarial pool",
"motor pool". Furthermore, we already use pool
to talk about allocation of (anonymous) parcels of
memory. My problem with hive and colony is similar:
bees/ants/termites are interchangeable, anonymous.

Traversal is not itself a distinguishing quality:
all of our containers are traversible. (Stack
and queue, note, are adapters.)

The difference *here* is that the traversal order
is a complex product of history. Any item inserted
will always appear in the same order relative to
other items that were already there; but otherwise
the order is indeterminate.

The sequential access is list-like, in that way:
we can insert items in lists without changing the
traversal order of existing elements. The difference
is that where an inserted item appears in that order
is unspecified; we have no concept of "insert
immediately after an iterator", or at the front
or end.

"Warehouse" is ok except that it already means
something in programming. Other alternatives in
that vein I think not already in use are "deposit"
and "rack".

But "slot_list" would be consistent with its
characteristics: elements live in slots, but are
traversed as in lists.

We prefer names that are shorter *not* because we
dislike typing; or just because they take up space
on the line we would like to use for our own names.
They occupy very strictly limited attention space:
more syllables in a Standard name means fewer
syllables available in mind for program names, when
reading unfamiliar code.

We are not *at all* short of usable names for this
thing, so a good choice is a matter of narrowing the
field by satisfying more criteria. Because so many
names are possible, we should be able to get an
optimal result on all axes.

Names do matter: a bad name choice does a literally
unbounded amount of harm, another bit for each use.
Most people are not good at choosing good names, but
some people are quite good. It is best to leave name
choices to people who have proven good at it.

Nathan Myers

On 2/13/21 9:45 AM, Tony V E via Lib-Ext wrote:
>
> +1 for pool
> Which at least one other person has also brought up (and crossed my mind
> earlier but I failed to list it).
>
> The only possible downside is that currently "pool" is a vague term -
> could be implemented many different ways,
> and now we would be locking it down to a particular implementation. The
> term will (eventually) take on that new meaning, at least in C++.
> But maybe that is fine.
>
> (Otherwise, stable_pool, etc)
>
>
> On Sat, Feb 13, 2021 at 11:55 AM Bjarne Stroustrup via Lib-Ext
> <lib-ext_at_[hidden] <mailto:lib-ext_at_[hidden]>> wrote:
>
> Brian storming: Please don't take it more serious than that.
>
> Here, I talk only about the name "colony"; I have nothing against the
> data structure.
>
> I don't like "colony"; I think it is out of character with other
> container type names and will attract hostility out of mere ignorance
> and is far too obvious target for rationalizations - (some) people
> always invent reasons for things being what they are, typically with
> scant regard for the original (historical) reasoning.
>
> We have a data structure into which we can place elements of one given
> type, can remove elements, where elements aren't relocated after
> allocation, and where the space for removed elements can be reused. If
> that's a fair description, I'd have (based on the traditions in my
> world) called it a pool. Correct so far?
>
> And then there is another crucial property that I don't usually
> associate with a pool: there is an ordered traversal. The order is not
> dependent on the values inserted or the order in which the elements are
> inserted; it is simply a way for users to traverse the data structure.
> Correct so far?
>
> So, two properties stick in my mind: pool and traversal. It's a
> container into which we can throw things and then look through them.
>
> bucket, pool, hive, slab, pail, tank, box, bag, ... are names of
> places
> where you can put things.
>
> Do we need to emphasize the possibility for traversal? I doubt it;
> if we
> decide on a name "X", we can/will say "you can traverse and X" and be
> done with it.
>
> Unfortunately, every good short word will cause problems with previous
> uses. One nice property of "colony" is exactly that many consider it a
> poor term for a container and so haven't used it.
>
> I guess that if we had thought of it years ago, we'd have called it
> "pool."
>
> Is any of the terms for a container "sufficiently unused" to be usable
> as std::X? If so, we have an opportunity. If not, what can we do to
> modify one of them to be "sufficiently odd" to become usable. Note
> Knuth's trick of naming "double-ended queue" deque.
>
> Assuming that the data structure will become popular, we would like a
> reasonably short name for it, say "tpool" rather than
> "traversable_pool"
> or "ipool" rather than "iteratable_pool"..
>
> PS. has anyone considered having a plain pool in addition to the one
> with traversal? People keep asking for a vector that's can't have its
> size changed after initialization (e.g., dynarray).
>
>
> On 2/11/2021 4:22 AM, Ville Voutilainen via Lib-Ext wrote:
> > On Thu, 11 Feb 2021 at 10:43, Jonathan Wakely via Lib-Ext
> > <lib-ext_at_[hidden] <mailto:lib-ext_at_[hidden]>> wrote:
> >> On Thu, 11 Feb 2021, 04:23 Matthew Bentley via Lib-Ext,
> <lib-ext_at_[hidden] <mailto:lib-ext_at_[hidden]>> wrote:
> >>> There's a number of false arguments here - the first is that
> metaphors have to be perfect, which they never are - and vector
> illustrates this perfectly.
> >> The name vector isn't just an imperfect metaphor, it's often
> considered to be just bad.
> > Yeah, that's correct. Technically correct, that is. It's also
> > irrelevant. Because here's how the conversion
> > goes with programmers, 120% of the time:
> > "std::vector is an array of contiguous elements with a run-time size,
> > and you can conveniently expand it,
> > so when you're reading that data from the UI, or a file, or a socket,
> > that's what you use for your buffers,
> > and you can expand the buffers by pushing more data to them in
> your loops."
> > "kthx, see you in code review."
> > "wait, don't you want to have philosophical discussion about why it's
> > a vector, not some *array"?
> > "*blank stare* don't have time time for that, I've got code to write,
> > you had me at hello, this is the
> > expandable buffer I need for my run-time data-read iterations, that's
> > all I need to know"
> >
> >>> This is close - however it describes one slot rather than many
> - and my prior reasoning stands. I've yet to hear a good argument as
> to why the current name is bad, and until I hear one, this
> discussion is not something I will be wasting time on.
> >> It's been a sticking point every time I've been in a group where
> it's been presented or reviewed.
> >> Arguably that's because it's easier to pick on the name and
> critique that rather than grok the technical details, but I don't
> think we can discount the fact that the name keeps being a blocker
> for people.
> > I'll bite. The name is problematic because it fails to communicate
> > what it tries to communicate. We can disagree on
> > why some people fail to grok that communication even after an
> > explanation (which is not how it would fail with
> > programmers instead of cabal priests), but that doesn't seem to be
> > succeeding to remove the communication
> > failure. The word means multiple things, and doesn't describe either
> > the conceptual structure or the expected API
> > of the container.
> >
> > A bucket_array, a bucket_list, a slab_list, a slab, a hive - all of
> > those would have fewer of these problems.
> > I could live with all of them. I don't prefer the words prefixing
> > array/list, because they're irrelevant, I don't
> > care that it stores things in buckets or slabs, I don't operate on
> > buckets or slabs when using a std::hive.
> > But if such a name gets it through, fine.
> > _______________________________________________
> > Lib-Ext mailing list
> > Lib-Ext_at_[hidden] <mailto:Lib-Ext_at_[hidden]>
> > Subscription:
> https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext__;!!KwNVnqRv!X57CnsgIJ3W_W6MqZYlOMYQ444Y6uyv57TT11yhBhi4qyUW4_Aboi5fmWuwgiA$
> <https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext__;!!KwNVnqRv!X57CnsgIJ3W_W6MqZYlOMYQ444Y6uyv57TT11yhBhi4qyUW4_Aboi5fmWuwgiA$>
> > Link to this post:
> https://urldefense.com/v3/__http://lists.isocpp.org/lib-ext/2021/02/17898.php__;!!KwNVnqRv!X57CnsgIJ3W_W6MqZYlOMYQ444Y6uyv57TT11yhBhi4qyUW4_Aboi5clRMhW4w$
> <https://urldefense.com/v3/__http://lists.isocpp.org/lib-ext/2021/02/17898.php__;!!KwNVnqRv!X57CnsgIJ3W_W6MqZYlOMYQ444Y6uyv57TT11yhBhi4qyUW4_Aboi5clRMhW4w$>
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden] <mailto:Lib-Ext_at_[hidden]>
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> <https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext>
> Link to this post: http://lists.isocpp.org/lib-ext/2021/02/17946.php
> <http://lists.isocpp.org/lib-ext/2021/02/17946.php>
>
>
>
> --
> Be seeing you,
> Tony
>
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2021/02/17947.php
>