Date: Thu, 11 Feb 2021 16:59:30 -0800
Apparently SG14 is supposed to get these too?
Date: Thu, 11 Feb 2021 08:47:33 -0800
From: Nathan Myers via Lib-Ext <lib-ext_at_[hidden]>
Reply-To: lib-ext_at_[hidden]
To: lib-ext_at_[hidden]
CC: Nathan Myers <ncm_at_[hidden]>
We like names that are
- long enough; the object must be distinguished from other
objects in its category
- short enough; we all have many other uses for the space
on any line of source code, and in our short-term memory,
which counts syllables, so a big name is a big evil.
- suggestive; while there is never enough room in a name
for a full spec, we all need a hint sometimes.
- accurate; an actively misleading name produces unbounded
confusion: it misleads everywhere it appears.
- direct; evoking extraneous associations burns attention.
- precise: it should not equally well refer to objects the
name does not.
- distinct: it should not sound or look much like other names.
All the "basic_"-this and "(un)stable_"-that fail on the last:
they make it harder to look names up in a sorted list, where
they all run together. It is much better to differ in the
first few characters than in the last few.
We are blessed to have only one actively misleading container
name, "vector", although we have all got used to it.
"set" and "map" are unfortunately imprecise. We got
"unordered_map/set" as a workaround for name-squatting, but
that is not a good reason to fail again on our own initiative.
A name that satisfies all of the above criteria, not suggested
yet, is "cote".
For those less fluent in English, it is used in e.g. "dovecote",
a house for pigeons, with a pigeonhole for each, first-come /
first-served.
The closest other suggestions are "hotel", "lot", "park",
and garage, which each evoke other, unwanted associations.
"Bucket" is imprecise. "Colony" is short enough, but evokes
many associations, none correct.
Another name that would work is "slot_list". While it is
an adjective_name form, both are short, and the associations
are correct. We have considered another slot container that
we might end up adopting, that would need to be distinguished
from it, which "_list" achieves; the other is more like a
slot_check or chit_array (randomly addressable via check, or
chit, returned on insertion).
The list of criteria at the top are worth retaining even if
"cote" is forgotten.
Nathan Myers
On 2/10/21 9:55 AM, Ben Craig via Lib-Ext wrote:
> My opinions on some of the names and name pieces I've seen (and some that I've suggested), bucketed in WF, N, WA, and SA.
>
> SA:
> * population: reused heavily in statistics. A population also has some sense of agency, where a container generally does not. I would not guess that something called std::population is a container. The name-by-analogy doesn't help me much here. The analogies I've heard apply equally well to other containers.
> * colony: Similar to population, a colony has some sense of agency. I wouldn't guess that this is a container, and the analogy doesn't help me much here. There are political / cultural issues with the name too.
> * _deque, *_allocator: The implementation has some similarities to deques and allocators, but the user interface of deque and allocator bears little to no resemblance to std::colony.
>
> WA:
> * lot, garage, park: These things don't have agency, which is an improvement, but none of these names feel like a container. The analogy is more helpful to me, but it still has to be explained.
> * parcel: I associated this with the mailing definition (e.g. parcel post). As a result, I didn't really get the analogy here even when it was explained. The "group of things" definition applies equally well to other containers.
> * _sparse: The implications on how much storage is used would be opposite what is used for matrices. A sparse matrix consumes less memory than a dense matrix. This container consumes more capacity (not necessarily size) than a "dense" std::list.
> * _store, _storage: All containers store things, so this doesn't really tell me anything. If we are going to add terms that don't help us decide between containers, then I'd rather they be more unique, like hive.
> * *_bundle, bag: Generic container word that has been used elsewhere with different meaning.
> **_sack: probably too close to bag?
> * *_deposit, *_dump: not things I would associate with a container, or iterating. Maybe that's because I don't go looking for old car parts frequently...
> * *_cluster: Other languages use the term cluster like we use struct. Clusters seem more heterogenous to me. The word does sound generically containerish though.
>
> N:
> * hive: hive feels more container like, and doesn't have agency. I could live with this name. I would prefer it say more about when to use the container. The name lacks a lot of positives, but it doesn't have any huge negatives either.
> * hotel: I like hive a little better than this one, though I'm not sure why. What I said about hive also applies to hotel.
> * stable_*: One of the big reasons to use this container is that references aren't invalidated. However, stable_ has meaning in the standard for algorithms. We also have a _lot_ of other containers which provide reference stability, but don't mention it in their names.
> * bucket_* and *_bucket: buckets certainly feel containerish, but don't really convey much information beyond that. The term is somewhat overloaded thanks to the unordered associative containers. A big bonus for using bucket is that many of the informal descriptions of the container use the word bucket as well. A negative is that other containers in the wild likely use the word container, and may mislead people as to what this thing does.
> * bucket_array: *_array in general feels like a trap due to the C and C++ expectations of what you can do with an array (contiguous storage, random access), but I think bucket_array is tolerable, largely because the container is often described as a bucket array.
> * skip_*: This describes some of the implementation, and not how the container is used. I can live with it, but I'm not thrilled with it.
>
> WF:
> * unordered_*. I like this because it tells you when (not) to use the container. Also, attaching this prefix to some other term helps make the other term "feel" more like a container than it would otherwise. If I saw "unordered_widget " (as an example), I would suspect the thing is a container, where I don't think I would feel the same about "widget" on its own.
>
> * _list: The iterators of std::colony are bidirectional. You can splice full containers. You have reference stability. It isn't tuned for lookup. These are all points in favor of list. The main thing I don't like about _list is the implication that it's a linked list. However, other languages use "list" for their main growable array type, so I don't think that's a show stopper.
>
>> -----Original Message-----
>> From: Lib-Ext <lib-ext-bounces_at_[hidden]> On Behalf Of Jeff Garland
>> via Lib-Ext
>> Sent: Wednesday, February 10, 2021 10:43 AM
>> To: lib-ext_at_[hidden]
>> Cc: Jeff Garland <jeff_at_[hidden]>; Peter Dimov
>> <pdimov_at_[hidden]>
>> Subject: [EXTERNAL] Re: [isocpp-lib-ext] std::colony name brainstorming
>>
>>
>>
>>> On Feb 10, 2021, at 9:38 AM, Peter Dimov via Lib-Ext <lib-
>> ext_at_[hidden]> wrote:
>>>
>>> Jeff Garland wrote:
>>>>> On Feb 10, 2021, at 8:59 AM, Bronek Kozicki via Lib-Ext > <lib-
>> ext_at_[hidden]> wrote:
>>>>>
>>>>> Here is a another naming idea: “store"
>>>>
>>>> I had been kicking ’storage’ around in my mind as well.
>>>
>>> I'm not sure how I feel about grabbing generic words in std:: in this manner.
>> "colony" is fine because there's hardly any chance of it being used for
>> something else, or misinterpreted, but some of the proposed replacements
>> aren't like that.
>>>
>>> If you were asked to guess what std::store did, what would you say? If you
>> were asked to guess what std::storage meant, what would you say?
>>
>> In my case I would have paired it with block_storage or bucket_storage or
>> unordered_bucket_store - not sure if that’s what Bronek had in mind. But I
>> self-eliminated for the reasons you’re citing — it’s just a bit too generic.
>>
>> Jeff
>> _______________________________________________
>> Lib-Ext mailing list
>> Lib-Ext_at_[hidden]
>> Subscription:
>> https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/lib
>> -
>> ext__;!!FbZ0ZwI3Qg!5CNJMXW04lEU0lO0bCL0DrB2lPmeeNeobEQGsVpnn5I
>> POLFj17Z1QhihZ10F$
>> Link to this post: https://urldefense.com/v3/__http://lists.isocpp.org/lib-
>> ext/2021/02/17857.php__;!!FbZ0ZwI3Qg!5CNJMXW04lEU0lO0bCL0DrB2lPme
>> eNeobEQGsVpnn5IPOLFj17Z1Qpm3uZbs$
> _______________________________________________
> 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/17865.php
>
_______________________________________________
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/17904.php
Date: Thu, 11 Feb 2021 08:47:33 -0800
From: Nathan Myers via Lib-Ext <lib-ext_at_[hidden]>
Reply-To: lib-ext_at_[hidden]
To: lib-ext_at_[hidden]
CC: Nathan Myers <ncm_at_[hidden]>
We like names that are
- long enough; the object must be distinguished from other
objects in its category
- short enough; we all have many other uses for the space
on any line of source code, and in our short-term memory,
which counts syllables, so a big name is a big evil.
- suggestive; while there is never enough room in a name
for a full spec, we all need a hint sometimes.
- accurate; an actively misleading name produces unbounded
confusion: it misleads everywhere it appears.
- direct; evoking extraneous associations burns attention.
- precise: it should not equally well refer to objects the
name does not.
- distinct: it should not sound or look much like other names.
All the "basic_"-this and "(un)stable_"-that fail on the last:
they make it harder to look names up in a sorted list, where
they all run together. It is much better to differ in the
first few characters than in the last few.
We are blessed to have only one actively misleading container
name, "vector", although we have all got used to it.
"set" and "map" are unfortunately imprecise. We got
"unordered_map/set" as a workaround for name-squatting, but
that is not a good reason to fail again on our own initiative.
A name that satisfies all of the above criteria, not suggested
yet, is "cote".
For those less fluent in English, it is used in e.g. "dovecote",
a house for pigeons, with a pigeonhole for each, first-come /
first-served.
The closest other suggestions are "hotel", "lot", "park",
and garage, which each evoke other, unwanted associations.
"Bucket" is imprecise. "Colony" is short enough, but evokes
many associations, none correct.
Another name that would work is "slot_list". While it is
an adjective_name form, both are short, and the associations
are correct. We have considered another slot container that
we might end up adopting, that would need to be distinguished
from it, which "_list" achieves; the other is more like a
slot_check or chit_array (randomly addressable via check, or
chit, returned on insertion).
The list of criteria at the top are worth retaining even if
"cote" is forgotten.
Nathan Myers
On 2/10/21 9:55 AM, Ben Craig via Lib-Ext wrote:
> My opinions on some of the names and name pieces I've seen (and some that I've suggested), bucketed in WF, N, WA, and SA.
>
> SA:
> * population: reused heavily in statistics. A population also has some sense of agency, where a container generally does not. I would not guess that something called std::population is a container. The name-by-analogy doesn't help me much here. The analogies I've heard apply equally well to other containers.
> * colony: Similar to population, a colony has some sense of agency. I wouldn't guess that this is a container, and the analogy doesn't help me much here. There are political / cultural issues with the name too.
> * _deque, *_allocator: The implementation has some similarities to deques and allocators, but the user interface of deque and allocator bears little to no resemblance to std::colony.
>
> WA:
> * lot, garage, park: These things don't have agency, which is an improvement, but none of these names feel like a container. The analogy is more helpful to me, but it still has to be explained.
> * parcel: I associated this with the mailing definition (e.g. parcel post). As a result, I didn't really get the analogy here even when it was explained. The "group of things" definition applies equally well to other containers.
> * _sparse: The implications on how much storage is used would be opposite what is used for matrices. A sparse matrix consumes less memory than a dense matrix. This container consumes more capacity (not necessarily size) than a "dense" std::list.
> * _store, _storage: All containers store things, so this doesn't really tell me anything. If we are going to add terms that don't help us decide between containers, then I'd rather they be more unique, like hive.
> * *_bundle, bag: Generic container word that has been used elsewhere with different meaning.
> **_sack: probably too close to bag?
> * *_deposit, *_dump: not things I would associate with a container, or iterating. Maybe that's because I don't go looking for old car parts frequently...
> * *_cluster: Other languages use the term cluster like we use struct. Clusters seem more heterogenous to me. The word does sound generically containerish though.
>
> N:
> * hive: hive feels more container like, and doesn't have agency. I could live with this name. I would prefer it say more about when to use the container. The name lacks a lot of positives, but it doesn't have any huge negatives either.
> * hotel: I like hive a little better than this one, though I'm not sure why. What I said about hive also applies to hotel.
> * stable_*: One of the big reasons to use this container is that references aren't invalidated. However, stable_ has meaning in the standard for algorithms. We also have a _lot_ of other containers which provide reference stability, but don't mention it in their names.
> * bucket_* and *_bucket: buckets certainly feel containerish, but don't really convey much information beyond that. The term is somewhat overloaded thanks to the unordered associative containers. A big bonus for using bucket is that many of the informal descriptions of the container use the word bucket as well. A negative is that other containers in the wild likely use the word container, and may mislead people as to what this thing does.
> * bucket_array: *_array in general feels like a trap due to the C and C++ expectations of what you can do with an array (contiguous storage, random access), but I think bucket_array is tolerable, largely because the container is often described as a bucket array.
> * skip_*: This describes some of the implementation, and not how the container is used. I can live with it, but I'm not thrilled with it.
>
> WF:
> * unordered_*. I like this because it tells you when (not) to use the container. Also, attaching this prefix to some other term helps make the other term "feel" more like a container than it would otherwise. If I saw "unordered_widget " (as an example), I would suspect the thing is a container, where I don't think I would feel the same about "widget" on its own.
>
> * _list: The iterators of std::colony are bidirectional. You can splice full containers. You have reference stability. It isn't tuned for lookup. These are all points in favor of list. The main thing I don't like about _list is the implication that it's a linked list. However, other languages use "list" for their main growable array type, so I don't think that's a show stopper.
>
>> -----Original Message-----
>> From: Lib-Ext <lib-ext-bounces_at_[hidden]> On Behalf Of Jeff Garland
>> via Lib-Ext
>> Sent: Wednesday, February 10, 2021 10:43 AM
>> To: lib-ext_at_[hidden]
>> Cc: Jeff Garland <jeff_at_[hidden]>; Peter Dimov
>> <pdimov_at_[hidden]>
>> Subject: [EXTERNAL] Re: [isocpp-lib-ext] std::colony name brainstorming
>>
>>
>>
>>> On Feb 10, 2021, at 9:38 AM, Peter Dimov via Lib-Ext <lib-
>> ext_at_[hidden]> wrote:
>>>
>>> Jeff Garland wrote:
>>>>> On Feb 10, 2021, at 8:59 AM, Bronek Kozicki via Lib-Ext > <lib-
>> ext_at_[hidden]> wrote:
>>>>>
>>>>> Here is a another naming idea: “store"
>>>>
>>>> I had been kicking ’storage’ around in my mind as well.
>>>
>>> I'm not sure how I feel about grabbing generic words in std:: in this manner.
>> "colony" is fine because there's hardly any chance of it being used for
>> something else, or misinterpreted, but some of the proposed replacements
>> aren't like that.
>>>
>>> If you were asked to guess what std::store did, what would you say? If you
>> were asked to guess what std::storage meant, what would you say?
>>
>> In my case I would have paired it with block_storage or bucket_storage or
>> unordered_bucket_store - not sure if that’s what Bronek had in mind. But I
>> self-eliminated for the reasons you’re citing — it’s just a bit too generic.
>>
>> Jeff
>> _______________________________________________
>> Lib-Ext mailing list
>> Lib-Ext_at_[hidden]
>> Subscription:
>> https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/lib
>> -
>> ext__;!!FbZ0ZwI3Qg!5CNJMXW04lEU0lO0bCL0DrB2lPmeeNeobEQGsVpnn5I
>> POLFj17Z1QhihZ10F$
>> Link to this post: https://urldefense.com/v3/__http://lists.isocpp.org/lib-
>> ext/2021/02/17857.php__;!!FbZ0ZwI3Qg!5CNJMXW04lEU0lO0bCL0DrB2lPme
>> eNeobEQGsVpnn5IPOLFj17Z1Qpm3uZbs$
> _______________________________________________
> 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/17865.php
>
_______________________________________________
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/17904.php
Received on 2021-02-11 18:59:37