John Doe wrote:IgorZ wrote: Тогда пока отложить на будущее?
Обсудить может быть полезно и сейчас.
Ну, тогда мой взгляд таков. С программной точки зрения это удобней всего видеть как таблицу. Скажем,
Code: Select all
{
{date=дата, version=версия, changes=изменения},
{...},
...
}
Или несимметричный вариант:
Code: Select all
{
version={date=дата, changes=изменения},
{...},
...
}
Дата, наверное, может быть необязательной. Симметричный (первый) вариант кажется мне навскидку более удобным, потому что он универсален и позволяет легко получить из себя любой другой.
В файле это можно указывать либо как таблицу (в этом случае формат записи очевиден) , либо как многострочный текст, подаваемый на вход специальной функции. Допустим, так:
Code: Select all
nfo:history[[
dd/mm/yyyy версия изменения
dd/mm/yyyy версия изме...
...нения
dd/mm/yyyy версия изменения
...
]]
За образец текста взял используемый мной шаблон оформления истории.
John Doe wrote:IgorZ wrote: И как заставить всех абсолютно авторов? Добавить код, рекурсивно обходящий папку Macros и удаляющий все файлы с "некошерными" расширениями? Ибо альтернативой - только добрая воля (субстанция куда более редкая, чем хотелось бы).
Не будем заставлять)
Если автор позаботился о регистрации скрипта, значит увидел для себя какую-то в этом пользу, и (будем надеяться) предварительно изучил прилагающуюся документацию.
Коллега, Вы противоречите самому себе. С одной стороны, автору будет лень писать несколько знаков дополнительно на каждый файл, с другой, ему не лень проделать работу по изучению документации, вставке nfo и, для уже имеющихся проектов, переименованию файлов и соответствующей переделке кода программы.
Как вариант, предложу компромиссный способ:
Code: Select all
files = [[
cfg:имя файла
lng:help:имя файла
lng:help:имя файла
lng:имя файла
]]
На строки я разбил для красоты. Суть в префиксе типа для имени - минимальная добавка для автора, которая легко парсится программно. Кстати, в принципе можно вместо префиксов использовать постфиксы, но мне кажется, спереди красивее.
John Doe wrote:IgorZ wrote: А если внутри Луа-код, то и расширение логично поставить .lua. Но при этом для соответствующего скрипта и то, и другое - файл настроек.
Файлы с расширением lua в папке scripts это скрипты. Они могут себя зарегистрировать сами, в частности используя и специальное поле для типа.
Аналогично, они могут быть зарегистрированы и из основного скрипта дополнительным вызовом Info.
И третий вариант, тип "настройки" например может быть определён и маской вида
*.cfg.*
(В следующей версии я уже ввёл типы, пока только в browser)
Файл языка или настроек с расширением .lua - не скрипт по смыслу. Писать отдельной nfo на каждый такой файл - излишне и даже, я бы сказал, противоречит главной идее. По расширениям я уже писал. Всё-таки описание типа - просто, компактно и универсально.
John Doe wrote:IgorZ wrote: Если, к примеру и языковые настройки, и справка находятся в одном файле (у самого в некоторых скриптах так), то отдельное поле типа позволит явно это указать, а ориентирование по расширению окажется бесполезно.
Используя Info вы можете предусмотреть и такую гипотетическую ситуацию, если это необходимо.
Info здесь избыточен, а значит, вреден. Всё-таки не стоит забывать, что эта информация должна ещё и легко восприниматься визуально, а nfo довольно объёмен. Один - ладно, но писать их в одном файле по штуке на каждый вспомогательный файл - явно лишне.
John Doe wrote:IgorZ wrote: крайне желателен символ, невозможный в имени переменной.
Знаю только один такой
\0
.
Ну а на практике вряд ли есть необходимость использовать даже слэш.
С другой стороны, использование таблицы позволило бы не делать никаких допущений о практике.
Думаю,
dbkey = {"GLOBAL","IgorZ","LuaManager"}
выглядит не особо элегантно. Да и писать неудобно. Наверное, лучше всего использовать слэш и удвоение, если надо:
dbkey = [[GLOBAL/IgorZ/Import//Export configuration]]
.