как назвать контейнер?

Первая реакция после шока - надо вводить какую-то номенкулатуру, типа марок сталей или кодов микросхем, кодировать аспекты контейнера буквами. 12Х18Н10Т, 1891ВМ4Я.

Назови как в жабе BitSet, ибо если я прравильно понимаю, именно его ты и сделал.

оно проживёт до момента, когда появится немутабельное

Квалификаторы типа const не завезли что-ли?

Местами завезли, но вопрос не в том. Мутабельный и иммутабельный контейнер вообще разные.

Мутабельный и иммутабельный контейнер вообще разные.

Где-то что-то пошло не так…

Не совсем BitSet, поменьше функций в этом. Ну и я его не делаю, просто придумываю правильное название. Сейчас он называется Bitmap. А я обнаружил, что это название условное, т.к. не полностью выражает суть. И тут выяснилось, что у любого контейнера полное название будет ужасно длинным. И в библиотеках обычно названия строятся на основе каких-то условностей.

IntSet - назначение же множество целых чисел, так?

Или RemainderSet<N>, т.к. это множество остатков от деления на N.

Вопрос в том, какие операции на типе определены (его public API).

Предназначение? Так то можно это дело и IntegerRangeMask назвать, и IntegerSet, и ещё по всякому.

+1 за bitset, потому как это именно то чем такой тип является как структура данных (в STL так называется, по крайней мере), и он довольно generic. А что он уж там логически из себя представляет в конкретном месте программы лучше выражать через имена соответствующих переменных.

Эх, никто не понял проблему. Понятно, что это битовый вектор с т.з. реализации. Но это ещё и контейнер, а у него есть ряд аспектов: мутабельность, потокобезопасность, фиксированность размера. Я этот назову bitset (вообще кто не понял тег Яр, то я всё по-русски называю, так что это будет БитовыйВектор). А завтра я заведу второй контейнер, такой же, но потокобезопасный. А послезавтра - потокоопасный, но иммутабельный. И т.п. Т.е. всё равно быстро появятся типы-контейнеры с ужасно длинными именами. Получается, что короткие имена, которые мы иногда можем наблюдать, какой-нибудь std::Vector - это условности что ли? Или это, наоборот, базовый класс, у которого никакие аспекты не определены? Как плодить типы контейнеров, чтобы имена их не стали столь ужасны и в то же время, чтобы имена чётко обозначали суть дела? Вот в чём вопрос-то.

Но это ещё и контейнер, а у него есть ряд аспектов: мутабельность, потокобезопасность, фиксированность размера.

Надо ли это всё отражать в именах - это вопрос к тому какие API типичны для классов в разрабатываемой системе. Т.е. если в основном от класса ожидается, что он мутабельный и непотокобезопасный, то такие указания надо опускать. Например, будет vector / immutable_vector (чтобы ни значило) / concurrent_vector. Для immutable подразумевается атомарность операций над объектами типа.

Ну и неплохо привести бы список имеющихся / планируемых контейнеров, а то может всё вполне описывается в виде «база» (указание на смысл + гарантии по алгоритмической сложности) + «модификатор» (один в подавляющем большинстве случаев).

Ещё как вариант можно использовать имена пакетов/пространства имён для различение вариантов контейнеров.

А послезавтра - потокоопасный, но иммутабельный.

А вот это надо хорошо постараться, чтобы сделать.

Ну и необходимость «потокобезопасного» варианта для каждого контейнера - очень сомнительна. Операции над контейнером будут конечно атомарными, но код его использующий необязательно автоматически будет потокобезопасным (см. на API boost::sync_queue vs std::queue).

Как плодить типы контейнеров, чтобы имена их не стали столь ужасны и в то же время,

Вот тут главный вопрос не в именах, а в том сколько контейнеров надо наплодить.

ПодмножествоФиксированногоОтрезкаЦелыхОтНуляДоЭнМутабельноеОднопоточноеБезЗащитыНаБитовомВекторе.

Выделенное жирным - это важная информация, остальное - нет.

Да, потокоопасный и мутабельный не бывает, но тут суть не в конкретных примерах, а вообще в большом количестве аспектов и их взаимодействии. Ещё несколько: персистентный, не выделяющий динамической памяти, пригодный для жёсткого реального времени, с оптимизированным хранением (уже не битовый вектор, а хеш-таблица, допустим).

Да, пространства имён можно задействовать в какой-то степени.

Ну и ещё есть особенность моей текущей деятельности - я не пишу код, а перевожу существующий. Поэтому я не знаю, сколько контейнеров впереди и нет оснований назвать тот, который мне первым попался, наиболее коротким именем.

не пишу код, а перевожу существующий. Поэтому я не знаю, сколько контейнеров впереди и нет оснований назвать тот, который мне первым попался, наиболее коротким именем

Тут стоит ориентировать на соотношение универсально/специализированного контейнера. В примере - явно специфическая вещь. Я бы следовал правилу - более универсальные средства имеют более короткие имена.

Ты сам увидел, что сообщать всю информацию о типе в его имени - непрактично. Строить короткие имена на базе системы соглашений об именовании - это не прижилось (хоть и использовалось, например, в LAPACK).

Можно и с другой стороны посмотреть - имена mapcar/reduce/filter не содержат информацию о том является ли их реализация tail recursive или нет (или там вообще цикл do), вычисляется ли результат сразу или отложено и т.д. Т.е. всё именование основывается на определённых условностях и выделении самой важной информации.

А как там было в LAPACK, можно примерчик? Я бы не сказал, что оно вообще нигде не прижилось. Микросхемы вполне себе так обозначаются, да и ещё есть куча других подобных номенкулатур. В автозапчастях вообще едва ли ни числовые коды, типа ip-адресов - и живут ведь как-то.

Т.е. всё именование основывается на определённых условностях и выделении самой важной информации.

Ну я и говорю, что фактически именование всегда условное. Единственное, на чём я в моей ситуации могу выехать - то, что это частный объект для модуля и он не экспортируется. Т.е. неважно, как он называется. Но если я хочу, чтобы в коде можно было нагрепать, где какой контейнер есть (а путь оберона - это не делать библиотеку контейнеров, а под каждый случай делать специализированный - хорошо это или нет - отдельная тема, но 40 Мб кода уже есть и решать это уже поздно), то мне нужна какая-то система именований, дружественная к поиску.

Про LAPACK - https://en.wikipedia.org/wiki/LAPACK#Naming_scheme

Я имел ввиду, что не прижилось в программировании.

Да, похоже, что примерно такое и придётся в конце концов применять. Но пока оставим это на уровне идеи.

потокоопасный, но иммутабельный

Это еще как.

Ну, представь, например, обертку к базе, которая кеширует результаты. Т.е. сам набор данных, к которые можно считать остаётся неизменным, но кеш в памяти изменяется (но пользователь класса этого не видит).

сам набор данных, к которые можно считать остаётся неизменным, но кеш в памяти изменяется

То есть в целом (вместе с кэшем) структура не иммутабельна.

Да это я не подумав ляпнул просто. Смысл в том, что сначала делается контейнер с каким-то набором свойств, и его называют коротким именем, потому что он пока единственный, или просто потому что он кажется самым важным и нужным. Потом появляются другие и оказывается, что имя первого контейнера уже не очень хорошее в новом контексте, что оно ad hoc, ничем не обосновано и делает ситуацию непонятной. Вместо иммутабельности и многопоточности можно взять любые аспекты.

Реализация - да мутабельная, просто это не видно через public API.

Смысл в том, что сначала делается контейнер с каким-то набором свойств, и его называют коротким именем, потому что он пока единственный

А пространства имен зачем придумали. Например, my.mutable.BitSet, my.immutable.BitSet. Или ты на elisp пишешь?

Хотя что-то мне подсказывает, что неплохо бы отразить в имени особенности/различия с точки зрения предметной области, а не детали реализации. Stack/Queue, а не LifoMutableArray/FifoImmutableList.

Смысл в том, что сначала делается контейнер с каким-то набором свойств, и его называют коротким именем, потому что он пока единственный, или просто потому что он кажется самым важным и нужным.

Так это к любому естественному языку относится. Имя заслуживает то, что часто встречается. Например, из паслёнов собственные имена имеют картошка и баклажан. Просто «паслён» подразумевает паслён чёрный. А всего их около 1200 видов.

Потом появляются другие и оказывается, что имя первого контейнера уже не очень хорошее в новом контексте

В естественных языках за это отвечают прилагательные