Идея: скрипты в метасимволах

Здесь обсуждается всё, что касается макросов.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

Идея: скрипты в метасимволах

Post by IgorZ »

Latest post of the previous page:

Предлагаю в список возвращаемых значений добавить true - команду не выполнять, пометку снять: функция уже сама всё сделала.
Может, вместо ... лучше таблицу? В ряде случаев это удобнее.
Все флаги в параметрах, наверное, логично убрать в State.
В итоге, функция будет выглядеть как имя(Item,State,Args)
Для Item, вероятно, наиболее логично использовать tPluginPanelItem.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Идея: скрипты в метасимволах

Post by John Doe »

IgorZ wrote: Fri 02 Nov, 2018 06:04 Предлагаю в список возвращаемых значений добавить true - команду не выполнять, пометку снять: функция уже сама всё сделала.
Подскажите в каком сценарии это может быть полезно.
IgorZ wrote: Fri 02 Nov, 2018 06:04 Может, вместо ... лучше таблицу?
... соответствует тому, как аргументы представлены при использовании метасимвола.
Это кстати тоже вполне вопрос для обсуждения, ведь можно и !lua!func {arg1=val1,arg2=val2} (имхо избыточно, но решать всё равно не мне).
IgorZ wrote: Fri 02 Nov, 2018 06:04 В ряде случаев это удобнее.
arg = {...}.
IgorZ wrote: Fri 02 Nov, 2018 06:04 Все флаги в параметрах, наверное, логично убрать в State.
Поясните.
IgorZ wrote: Fri 02 Nov, 2018 06:04 Для Item, вероятно, наиболее логично использовать tPluginPanelItem.
Да, но см. fnparce.cpp: я вовсе не уверен что эта информация там доступна.
Также вспомните, что на плагиновых панелях Применить Команду вообще не реализовано, а при использовании ассоциаций элемент распаковывается во временную папку, и это уже совсем не tPluginPanelItem. Edit
При использовании ассоциаций из командной строки аналогично, элемент не принадлежит панели.
Last edited by John Doe on Tue 13 Nov, 2018 12:27, edited 1 time in total.
User avatar
Smitis
Posts: 1709
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 23 times
Been thanked: 55 times

Идея: скрипты в метасимволах

Post by Smitis »

Имхо, в идеале было лучше что-то типа ![=[выражение lua]=], тогда не нужно будет описывать никаких отдельных Symbol. Вместо [=[ в случае необходимости использовать [==[ [===[ и т.д.
Last edited by Smitis on Sun 04 Nov, 2018 19:56, edited 1 time in total.
Разум когда-нибудь победит.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Идея: скрипты в метасимволах

Post by John Doe »

Smitis wrote: Sun 04 Nov, 2018 19:56 тогда не нужно будет описывать никаких отдельных Symbol.
Разве вы только что не описали отдельный символ, своего рода?
(Имхо, не очень. Громоздко.)
User avatar
Smitis
Posts: 1709
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 23 times
Been thanked: 55 times

Идея: скрипты в метасимволах

Post by Smitis »

John Doe
А писать отдельные конструкции это не громоздко? И вообще, зачем плодить лишние сущности?
Разве вы только что не описали отдельный символ, своего рода?
Так можно сказать о любом метасимволе. Я не настаиваю именно на конструкции именно [=[ ]=], но что-то типа такого упростит синтаксический разбор строки.
Last edited by Smitis on Mon 05 Nov, 2018 13:09, edited 1 time in total.
Разум когда-нибудь победит.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Идея: скрипты в метасимволах

Post by John Doe »

Smitis wrote: Mon 05 Nov, 2018 13:09 А писать отдельные конструкции это не громоздко? И вообще, зачем плодить лишние сущности?
Вы имеете ввиду, что не нужно никак специально определять подстановочные функции (то что расписано тут: viewtopic.php?p=151184#p151184).

Не могу с этим согласиться (учитывая все описанные в том посте ньюансы).

P.S.
Я не возражаю, что может быть удобно указывать выражение прямо в метасимволе. Используя предложенный мной подход это ведь тоже возможно.
Last edited by John Doe on Mon 05 Nov, 2018 13:20, edited 1 time in total.
User avatar
Smitis
Posts: 1709
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 23 times
Been thanked: 55 times

Идея: скрипты в метасимволах

Post by Smitis »

John Doe wrote: Mon 05 Nov, 2018 13:17 Вы имеете ввиду, что не нужно никак специально определять подстановочные функции
Да. В моём варианте в качестве подстановочных функций можно использовать ОБЫЧНЫЕ функции lua как частный случай. Параметры передавать как ... ![==[func(...)]==]
Разум когда-нибудь победит.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Идея: скрипты в метасимволах

Post by John Doe »

John Doe wrote: Mon 05 Nov, 2018 13:17 Используя предложенный мной подход это ведь тоже возможно.
Предположим, у нас уже определена функция eval (а это можно хоть из коробки), тогда в моём варианте всё можно сделать похожим образом:

Code: Select all

!*eval[[func(...)]]
Smitis wrote: Mon 05 Nov, 2018 13:09 но что-то типа такого упростит синтаксический разбор строки.
Об разборе действительно стоит подумать.
User avatar
Smitis
Posts: 1709
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 23 times
Been thanked: 55 times

Идея: скрипты в метасимволах

Post by Smitis »

John Doe wrote: Mon 05 Nov, 2018 14:25 Предположим, у нас уже определена функция eval (а это можно хоть из коробки), тогда в моём варианте всё можно сделать похожим образом
Вот! Всё тоже самое, только Вы предлагаете для этого некие специальные программные конструкции, а я предлагаю обойтись штатными средствами.
Разум когда-нибудь победит.
User avatar
Smitis
Posts: 1709
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 23 times
Been thanked: 55 times

Идея: скрипты в метасимволах

Post by Smitis »

John Doe wrote: Thu 01 Nov, 2018 11:46 Осталась неопределённость с параметрами action
А зачем вообще параметры? Если нужен список выделенных файлов, текущий файл и пр. то их можно получить через api.
John Doe wrote: Wed 31 Oct, 2018 13:59 Кроме того, если идея получит развитие, то возможны дополнения, например дополнительный запуск функции после обработки нескольких выделенных файлов.
Опять таки, в моём случае, вызвали функцию, функция обработала выделенные файлы, если нет выделенного - текущий файл, потом сняла выделение, потом ещё что-то выполнила, потом вернула значение, которое подставилось на место метасимвола.
Разум когда-нибудь победит.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

Идея: скрипты в метасимволах

Post by IgorZ »

John Doe wrote: Fri 02 Nov, 2018 08:25
IgorZ wrote: Fri 02 Nov, 2018 06:04 Предлагаю в список возвращаемых значений добавить true - команду не выполнять, пометку снять: функция уже сама всё сделала.
Подскажите в каком сценарии это может быть полезно.
Предлагалось, исходя из общих соображений: это единственный возможный результат, не отражённый в списке вариантов. Но пример придумать нетрудно.
Например, когда для части выделенных файлов требуется выполнить два действия (одно по команде, другое в функции), а для остальных - только одно. Скажем, мы выделили кучу текстовых файлов, из них надо выбрать данные, а часть из файлов ещё и заархивировать.
Или ещё проще: мы выделили кучу текстовых файлов, часть из них надо заархивировать, часть не трогать. Что, не тронутые так и должны оставаться выделенными?
John Doe wrote: Fri 02 Nov, 2018 08:25
IgorZ wrote: Fri 02 Nov, 2018 06:04 Может, вместо ... лучше таблицу?
... соответствует тому, как аргументы представлены при использовании метасимвола.
Это кстати тоже вполне вопрос для обсуждения, ведь можно и !lua!func {arg1=val1,arg2=val2} (имхо избыточно, но решать всё равно не мне).
Так ведь всё, здесь написанное, по определению - вопрос для обсуждения.
John Doe wrote: Fri 02 Nov, 2018 08:25
IgorZ wrote: Fri 02 Nov, 2018 06:04 В ряде случаев это удобнее.
arg = {...}.
Ну, в принципе, можно и так. Хотя я исхожу из того, что таблица гораздо практичнее в большинстве случаев.
John Doe wrote: Fri 02 Nov, 2018 08:25
IgorZ wrote: Fri 02 Nov, 2018 06:04 Все флаги в параметрах, наверное, логично убрать в State.
Поясните.
Это тоже состояние.
John Doe wrote: Fri 02 Nov, 2018 08:25
IgorZ wrote: Fri 02 Nov, 2018 06:04 Для Item, вероятно, наиболее логично использовать tPluginPanelItem.
Да, но см. fnparce.cpp: я вовсе не уверен что эта информация там доступна.
Также вспомните, что на плагиновых панелях Применить Команду вообще не реализовано, а при использовании ассоциаций элемент распаковывается во временную папку, и это уже совсем не tPluginPanelItem.
При использовании ассоциаций из командной строки аналогично, элемент не принадлежит панели.
Ну, с наполнением полей таблицы надо думать, а саму структуру удобно взять готовую, по мере необходимости добив дополнительными полями (исходный путь, к примеру).
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Идея: скрипты в метасимволах

Post by John Doe »

Smitis wrote: Mon 05 Nov, 2018 16:09 Вот! Всё тоже самое, только Вы предлагаете для этого некие специальные программные конструкции, а я предлагаю обойтись штатными средствами.
Именно так, я считаю, что подстановочные функции достаточно специфичны.
Сомневаюсь, что конструировать функцию прямо в метасимволе будет распространённой практикой.
Чаще удобнее иметь предварительно заданные функции, и даже если задавать их штатным образом, то удобнее (на практике) держать их вместе, в отдельной таблице, типа _G.symbol.
В итоге, использование отдельного загрузчика видится мне предпочтительным, поскольку предоставляет дополнительные удобства по администрированию метасимволов (наряду и с другими загружаемыми сущностями: макросами, событиями, и др.)
И второй момент: гибкость, потенциальная и реальная (например предлагаемый флаг OnceForSelected).
Smitis wrote: Mon 05 Nov, 2018 16:21 А зачем вообще параметры? Если нужен список выделенных файлов, текущий файл и пр. то их можно получить через api.
Например, чтобы передать источник вызова, и др. свойства (см. мою спецификацию).
Выделенный файл мы конечно через апи получим, но что если это вызов по ассоциации из архива? Как нам получить имя распакованного файла во временной папке?
Альтернативой параметрам может быть переменная из окружения функции (об этом тоже сказано в спецификации).
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Идея: скрипты в метасимволах

Post by John Doe »

IgorZ wrote: Tue 06 Nov, 2018 06:59 Предлагалось, исходя из общих соображений: это единственный возможный результат, не отражённый в списке вариантов.
Тоже думал об этом, но сознательно отказался, поскольку на практике вариант получается лишний.
IgorZ wrote: Tue 06 Nov, 2018 06:59 Например, когда для части выделенных файлов требуется выполнить два действия (одно по команде, другое в функции), а для остальных - только одно. Скажем, мы выделили кучу текстовых файлов, из них надо выбрать данные, а часть из файлов ещё и заархивировать.
Или ещё проще: мы выделили кучу текстовых файлов, часть из них надо заархивировать, часть не трогать. Что, не тронутые так и должны оставаться выделенными?
Этот случай предусмотрен в спецификации, флаг SelectedAtOnce.
IgorZ wrote: Tue 06 Nov, 2018 06:59 Это тоже состояние.
Спецификация конечно же предварительная, и я специально не делал попыку что-либо из параметров объединять/группировать в Params.
Но да, это может быть что угодно, например и позиционные аргументы action(Params,State,Item,...), где флаги объединены в Params.

А вот конкретно в State я пожалуй не хотел бы их добавлять, потому что по замыслу этим состоянием должна управлять сама функция, и будет удобнее не иметь там ничего лишнего, например во избежание конфликтов.
Возможно, лучше назвать аргумент иначе.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

Идея: скрипты в метасимволах

Post by IgorZ »

John Doe wrote: Tue 06 Nov, 2018 10:01
IgorZ wrote: Tue 06 Nov, 2018 06:59 Предлагалось, исходя из общих соображений: это единственный возможный результат, не отражённый в списке вариантов.
Тоже думал об этом, но сознательно отказался, поскольку на практике вариант получается лишний.
Не лишний, см. ниже.
John Doe wrote: Tue 06 Nov, 2018 10:01
IgorZ wrote: Tue 06 Nov, 2018 06:59 Например, когда для части выделенных файлов требуется выполнить два действия (одно по команде, другое в функции), а для остальных - только одно. Скажем, мы выделили кучу текстовых файлов, из них надо выбрать данные, а часть из файлов ещё и заархивировать.
Или ещё проще: мы выделили кучу текстовых файлов, часть из них надо заархивировать, часть не трогать. Что, не тронутые так и должны оставаться выделенными?
Этот случай предусмотрен в спецификации, флаг SelectedAtOnce.
Как я понимаю, SelectedAtOnce означает "обработать все скопом". А файлы, в данном случае, необходимо упаковать каждый в свой архив, то есть, выполнять команду для каждого отдельно.
Кстати, приводя пример, упустил ещё одну деталь. Более приближённый к практике вариант: "Эта карточка закрыта, вес подсчитать, её упаковать и в архив; эта карточка ещё открыта, вес подсчитать, снять пометку; а вот в этой, похоже, ошибка, ничего не делать, пометку не снимать".
John Doe wrote: Tue 06 Nov, 2018 10:01
IgorZ wrote: Tue 06 Nov, 2018 06:59 Это тоже состояние.
Спецификация конечно же предварительная, и я специально не делал попыку что-либо из параметров объединять/группировать в Params.
Но да, это может быть что угодно, например и позиционные аргументы action(Params,State,Item,...), где флаги объединены в Params.
А вот конкретно в State я пожалуй не хотел бы их добавлять, потому что по замыслу этим состоянием должна управлять сама функция, и будет удобнее не иметь там ничего лишнего, например во избежание конфликтов.
Возможно, лучше назвать аргумент иначе.
Состоянием управляет сама функция. Но начальное-то состояние мы всё равно задаём. Просто часть состояния изменяется в процессе, а часть нет. Что же до конфликтов, так на то и придумано понятие "зарезервированные имена".
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Идея: скрипты в метасимволах

Post by John Doe »

IgorZ wrote: Tue 06 Nov, 2018 11:37Кстати, приводя пример, упустил ещё одну деталь. Более приближённый к практике вариант: "Эта карточка закрыта, вес подсчитать, её упаковать и в архив; эта карточка ещё открыта, вес подсчитать, снять пометку; а вот в этой, похоже, ошибка, ничего не делать, пометку не снимать".
Если принять такую задачу, то действительно может понадобиться отдельный сигнал.
Принципиальных возражений не имею, но будучи сторонником минимализма, предпочёл бы обойтись: (далее имхо, можно не отвечать)
IgorZ wrote: Tue 06 Nov, 2018 11:37Состоянием управляет сама функция. Но начальное-то состояние мы всё равно задаём. Просто часть состояния изменяется в процессе, а часть нет. Что же до конфликтов, так на то и придумано понятие "зарезервированные имена".
Я согласен, что можно объединить в одной таблице всё что угодно: и флаги, и "состояние", которым управляет функция, и не возражаю, если автор так и решит сделать.

Но всё равно хочу подчеркнуть: State в спецификации подразумевает независимый аргумент, который даже не обязан быть таблицей.
Его можно передавать как отдельной позицией, так и в таблице, в числе прочих (например Param.State).
Но я против того, чтобы объявлять состоянием всю таблицу Param, потому что получившийся микс не видится мне красивым решением (зачем эта возня с зарезервированными именами, если её можно избежать).
Last edited by John Doe on Tue 06 Nov, 2018 12:49, edited 1 time in total.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

Идея: скрипты в метасимволах

Post by IgorZ »

John Doe wrote: Tue 06 Nov, 2018 12:14 Принципиальных возражений не имею, но будучи сторонником минимализма, предпочёл бы обойтись.
Ну, тут вопрос, где проходит разумная граница между минимализмом и выбрасыванием заведомо нужного функционала, который всё равно, по моему мнению, придётся добавлять, если новый механизм окажется востребованным. Я считаю, что данный вариант возвращаемого результата всё равно окажется нужным, так что проще сразу его добавить, чем потом допиливать с риском что-то поломать (не у себя, так у какого-нибудь пользователя).
John Doe wrote: Tue 06 Nov, 2018 12:14
IgorZ wrote: Tue 06 Nov, 2018 11:37Состоянием управляет сама функция. Но начальное-то состояние мы всё равно задаём. Просто часть состояния изменяется в процессе, а часть нет. Что же до конфликтов, так на то и придумано понятие "зарезервированные имена".
Я согласен, что можно объединить в одной таблице всё что угодно: и флаги, и "состояние", которым управляет функция, и не возражаю, если автор так и решит сделать.

Но всё равно хочу подчеркнуть: State в спецификации подразумевает независимый аргумент, который даже не обязан быть таблицей.
Его можно передавать как отдельной позицией, так и в таблице, в числе прочих (например Param.State).
Но я против того, чтобы объявлять состоянием всю таблицу Param, потому что получившийся микс не видится мне красивым решением (зачем эта возня с зарезервированными именами, если её можно избежать).
Подумав, решил считать это непринципиальным вопросом. Возврат true - существенный момент, передача аргументов в виде таблицы - не столь существенный, но удобный для обработки пользователем. Остальное обсуждавшееся вполне допустимо и так, и этак.
Post Reply

Return to “Обсуждение макросов”