Здравствуйте, Sm0ke, Вы писали:
S>4. Рассмотрю ещё предложения и другие идеи
А можно ещё оставить всё как есть, то есть just::. По сути все твои предложения сводятся к созданию ненужной смысловой нагрузки для систематизации.
1. Первый вариант вложенные пространства имён.
2. Второй вариант несколько пространств имён одного уровня (окончания).
3. Третий вариант вариации на тему венгерской нотации (приставки).
Исследуя способы организации информации я пришёл к выводу, что она фрагментарна.
Систематизация личной базы знаний по программированию в Zim
И вот тут возникает другая проблема. Чужой источник знаний можно не систематизировать. Книгу записать согласно оглавлению. Код согласно файловой системе. Но с собственными знаниями такой трюк не прокатит, так как они фрагментарны.
Да, мозгу гораздо проще выхватывать фрагменты с источника знаний, обрабатывать, и возвращать в источник знаний в виде изменений создавая новые знания. Потому при систематизации личной базы знаний важно уметь добавлять знания с отложенной систематизацией.
Основная фишка в том, что систематизации нет, а вместо этого есть предметный каталог. В твоём случае just:: это пространство имён, которое не даёт твоим собственным именам пересекаться с чужими именами. Оно же является предметным каталогом в твоей библиотеке. Именно этот принцип я и заложил в основу личной базы знаний.
1. Выдели предметные каталоги, у тебя это just::.
2. Положи туда все понятия, которые посчитаешь нужными.
3. Получай доступ к понятиям с помощью предметного каталога.
*. Можешь когда-нибудь создать документацию в котором понятия из предметного каталога будут систематизированы.
Вот так оно должно выглядеть в алфавитном порядке, если считать классы и шаблоны имён в одном предметном каталоге.
just::button
just::concat<>
just::concat_separated<>
just::form
Что касается подпространств имён, таких как
just::literals:: // sub namespace
Если это конечно подпространство имён, то в принципе можно засунуть в него все литералы, если они в противном случае были бы глобальными или смешивались с классами, то есть создать предметный подкаталог.
По моей теории допустимо разделять на предметные каталоги и на предметные подкаталоги входящие в предметные каталоги по типу элементов, но не по систематизации.
Если заглянуть в историю, то начинал я с каталогизации в файловой системе, а вовсе не с личной базы знаний. Оказалось, что удобнее всего использовать линейный список по типу входящих элементов.
Например, делаешь папку distros и засовываешь в него все дистрибутивы программ за исключением игр, потому что игры я считаю за отдельные дистрибутивы.
distros
1c
3dobjectconverter
3dsmax
7zip
adobeaftereffects
adobedreamweaver
aida64
akapella
alcohol
alfresco
alldup
androidstudio
anki
aomeipartitionassistant
archicad
arduinoide
asciiartstudio
audacity
autocad
...
И так же всё остальное, типа anime, audiobooks, books, distros, lessons, manga, movies, music, podcast, ranobes, serials, youtube. С этой системой я наконец получил огромное преимущество, предотвращающее превращение диска в файлопомойку из интернета.
Подумай вот над чем, систематизация вместо предметного каталога не даст тебе никаких реальных преимуществ. А недостатков куча, такие как прописывание абсолютно ненужных систематизирующих имён, или ненужных систематизирующих приставок или окончаний, нескольких using namespace вместо одного.
И вот представь, потом ты решишь, что тебе надо сменить систематизацию, например, класс оказался не в том пространстве имён. Это же просто замечательный квест по изменению кода, особенно если ты не единственный пользователь.
Да есть автоматические функции рефакторинга по переименованию, но кто-то мог уже наставить кучу using namespace. И самое главное ещё раз повторяю, предметный каталог по типу элементов имеет значение, а систематизация создаёт "грязные" имена, которые будут отвлекать твой мозг в будущем на их осмысление.
В предметном каталоге just:: можно объединить шаблоны+классы, может даже +перечисления, так как это типы созданные пользователем. Сделать подкаталог литералов just::literals::, потому что литералы это не типы созданные пользователем, а закодированные данные.
И пространство имён сделает из этих данных единый модуль. Опять же это может быть удобно чтобы всякая мелочь не мешалась в главном предметном каталоге типов определяемых пользователем. Или можно покурить тему насчёт статических литералов в классе или структуре, то есть сделать так just::literals, а не так just::literals::.
Можешь попробовать разные варианты сам. Я ведь тоже до предметных каталогов пробовал всякое, в том числе с пространствами имён, и получалась всякая ерунда, которая не давала мне ничего, но требовала "обслуживания" на каждом шагу написания кода.
Для программных проектов удобнее без пространств имён. Для библиотек алгоритмов, особенно если хочешь их распространять на несколько проектов и другим людям, такое может оказаться неудобным.
Тот же Qt просто огромный, но там люди не стали извращаться с кучей пространств имён. Буковка Q вначале это конечно не путь тру программиста C++, но одно пространство имён для всей библиотеки алгоритмов вполне. А для исполняемой программы можно ничего не делать, и так сойдёт.
Я последний раз повторю главную мысль, чисто технически пространства имён созданы не для систематизации, а для того, чтобы имена созданные разными независимыми группами программистов объединяемые в одном проекте не пересекались.
