Page 4 of 10

Реализация Condensed View

Posted: Sun 26 Jul, 2015 12:38
by buniak_a_h

Latest post of the previous page:

John Doe wrote: Я бы записал так:
local function IsEditorActive()
 local ei = editor.GetInfo()
 return ei and EditorsCondView[ei.EditorID]
end;
, соответственно функция IsMacroActive вообще стала бы лишней.
Разбил на две функции (проверки наличия контекста редактора и активности макроса) при борьбе с ExitFAR. Не получилось, но возвращать обратно не стал, т.к. не мешает.
John Doe wrote: (...) и никаких плюсов взамен.
1. Не нужно каждый раз писать проверку, не nil ли GetInfo()
2. Не нужно при каждом вызове макроса перечитывать GetInfo, проверять существование EditorsCondView[EID]. Можно, конечно, оставить эти действия в процедуре (как сейчас), но тогда её вызывать в каждом action{/c]. А какая разница? Тоже самое, но один раз написал и забыл. Впрочем, дело вкуса.
3. А общие переменные для всех функций в данном случае, по-моему, это правильно. Отражает, что это - реально одно и то же.

[quote="Shmuel"][post]131522[/post] Зачем гадать, не легче ли прочитать соответствующую статью[/quote]
Прочитал, потому и был спокоен. Раз появились замечания, то (а) я неправильно понял описание; или (б) описание не соответствует программе (программирую с 1974-го года, с таким сталкивался часто. Если Вы не сталкивались - что ж, молод истчо! :quiet: ); или (в) из-за ошибки в программе есть ситуации, когда [b]condition[/b] не выполняется. Или в ФАРе нет ошибок?

Реализация Condensed View

Posted: Sun 26 Jul, 2015 13:01
by John Doe
buniak_a_h wrote: Не нужно каждый раз писать проверку, не nil ли GetInfo()
Каждый раз перед использованием GetInfo надо вызывать, и продолжать работу только при наличии значения. Не вижу как общие переменные в этом могут помочь.
buniak_a_h wrote: Не нужно при каждом вызове макроса перечитывать GetInfo, проверять существование EditorsCondView[EID].
Избежать повторения одних и тех же операций в condition/action — это аргумент.
Но и в этом случае есть смысл максимально ограничить область действия общих переменных.
buniak_a_h wrote: А общие переменные для всех функций в данном случае, по-моему, это правильно. Отражает, что это - реально одно и то же.
Одинаковые имена переменных и параметров отражаю всё что надо.
А область действия переменных должна быть не больше, чем необходима.

Но можете конечно игнорировать моё мнение, я вообще не программист.

Реализация Condensed View

Posted: Sun 26 Jul, 2015 13:21
by Shmuel
buniak_a_h wrote: (программирую с 1974-го года, с таким сталкивался часто. Если Вы не сталкивались - что ж, молод истчо!
Да, против таких аргументов не попрёшь.

Реализация Condensed View

Posted: Sun 26 Jul, 2015 13:36
by buniak_a_h
John Doe wrote: Каждый раз перед использованием GetInfo надо вызывать, и продолжать работу только при наличии значения. Не вижу как общие переменные в этом могут помочь.
Не общие переменные - этим занимается IsEditorActive, который вызывается в condition
John Doe wrote: Одинаковые имена переменных и параметров отражаю всё что надо.
Увы, не привык полагаться на имена. Есть "специалисты", дающие переменным имена типа ii, iii, iiii и т.д. ; есть языки программирования (интерпретаторы), скорость работы которых сильно зависит от длины имен переменных (в частности, при использовании в Clipper-программе 1-2-символьных имён переменных скорость выполнения выше раз в 5-7, чем при нормальных именах). Опять же, статические переменные - это выше скорость, чем из стека. Наверно, "отрыжка" тех времён, когда эффективность кода имела значение...
Небольшой вопрос:
John Doe wrote:

Code: Select all

local function IsMacroActive()
  EID = IsEditorActive()
  isActive = EID and EditorsCondView[EID]
  return isActive
end;
В этом фрагменте переменная isActive не объявлена local. Это - ошибка, или специально она глобальная ? Или я опять языке запутался?

Реализация Condensed View

Posted: Sun 26 Jul, 2015 13:48
by John Doe
buniak_a_h wrote: Не общие переменные - этим занимается IsEditorActive, который вызывается в condition
Я тут критикую избыточную область действия переменных ei, EID, объявленных в самом начале скрипта.
Утверждаю, что общие переменные необходимы только в макросах, для передачи значений из condition в action (поскольку других механизмов для этого не предусмотрено).
У вас же эти переменные общие для всех функций, что чревато багами (потенциально), и делает код запутанным, т.к. глядя на функцию я без понятия откуда пришло значение той или иной переменной.
buniak_a_h wrote: фрагменте переменная isActive не объявлена local. Это - ошибка, или специально она глобальная ? Или я опять языке запутался?
В коде из прошлого сообщения я пытался продемонстрировать разумное использование общих переменных, EID и isActive.

P.S.
Но если быть параноиком (к чему я не призываю), то есть смысл в action получать значения заново, т.к. между condition и action состояние может измениться. Ситуация не штатная, но возможная.

Реализация Condensed View

Posted: Sun 26 Jul, 2015 14:16
by buniak_a_h
John Doe wrote: Но если быть параноиком...
Поначалу я так и сделал. Но Вы меня сбили замечанием, что GetInfo может вернуть и nil. Поэтому я решил проверять его результат сразу в condition, и больше уже не переспрашивать до тех пор, пока не я сам не решу, что что-то могло измениться. Просто тогда непонятно, что делать дальше...

Реализация Condensed View

Posted: Sun 26 Jul, 2015 14:18
by HaRT

Реализация Condensed View

Posted: Sun 26 Jul, 2015 14:22
by John Doe
buniak_a_h wrote: Просто тогда непонятно, что делать дальше...
Жаль, значит я напрасно старался.

Реализация Condensed View

Posted: Sun 26 Jul, 2015 14:45
by buniak_a_h

Реализация Condensed View

Posted: Sun 26 Jul, 2015 15:04
by buniak_a_h
John Doe wrote: Жаль, значит я напрасно старался.
Это вы о моём просвещении?
(а) Вы так и не описали ситуацию, в которой GetInfo возвращает nil, у меня смоделировать такое не получилось, так что как тестировать - не представляю.
(б) А действительно, как должен поступить скрипт, если в condition GetInfo вернула таблицу, а в action - уже нет? Я вот просто не знаю, что в таком случае делать. То ли прекращать скрипт и подчищать за собой переменные (таблицы), то ли подождать микросекундочку и запросить GetInfo снова...
И, кстати, по поводу
John Doe wrote:
buniak_a_h wrote:Увы, editor.GetInfo приходится вызывать каждый раз, когда делается что-нибудь (перемещение по файлу, выход с или без сохранения позиции).
Естественно! Информация-то меняется.
Тут могут быть два подхода (в учебниках это называлось передачей по ссылке или по значению): GetInfo может вернуть саму таблицу (т.е. образовать новую переменную и заполнить её), либо ссылку на некую внутреннюю структуру редактора, содержащую эту информацию. Во втором случае GetInfo достаточно вызвать один раз; все изменения состояния редактора автоматически будут видны в возвращаемой таблице. И как в ФАРе это реализовано, я не знаю. Так что ирония неуместна.

Реализация Condensed View

Posted: Sun 26 Jul, 2015 15:12
by Shmuel
John Doe
Мне кажется, имеет смысл подождать (неделю, месяц, год) пока наш уважаемый (без иронии) программист со стажем освоит азы Lua и FAR API, вместо того, чтобы опираться на свой большой опыт в других областях программирования. Зачем зря тратить ваше время.

Реализация Condensed View

Posted: Sun 26 Jul, 2015 15:24
by John Doe
buniak_a_h wrote: как тестировать - не представляю.
В Энциклопедии, которая для нас является основным руководством, для каждой функции зачем-то предусмотрена возможность неуспеха.
Вероятно для того, чтобы в своём коде мы могли это как-то учесть.
Как тестировать, это другой вопрос, подозреваю что философский.
buniak_a_h wrote: как должен поступить скрипт, если в condition GetInfo вернула таблицу, а в action - уже нет?
Не выполнять действий. Никаких.
Но если вы не параноик, то в данном случае такой возможностью можно и пренебречь, тем более других проблем хватает.
buniak_a_h wrote: (т.е. образовать новую переменную и заполнить её)
Именно так.
Shmuel wrote: Зачем зря тратить ваше время.
Человек изначально не собирался ничего совершенствовать, а я его чуть ли не заставил, поэтому и трачу.
Тем более идея скрипта заинтересовала (хотя конечно уже бы и сам написал).

Реализация Condensed View

Posted: Sun 26 Jul, 2015 15:42
by buniak_a_h
John Doe wrote: Тем более идея скрипта заинтересовала (хотя конечно уже бы и сам написал)
Я просил, никто не взялся. Сделаете по уму - буду только рад.
Shmuel wrote: Мне кажется, имеет смысл подождать (неделю, месяц, год) пока (...) программист со стажем освоит азы Lua и FAR API
У меня есть работа, и изучать язык ради одного скрипта я не буду. У меня - работает. Вызывать macro:load или macro:unload во время активного макроса ни я, ни мои сотрудники не собираемся. Обрабатывать (гипотетическую) ситуацию, из-за которой контекст макро выгрузится из памяти я тоже не хочу.
Итак: а Вас есть выбор.
1. Дописать (исправить) то, что работает, и разместить или в "полезных макросах", или на ринге.
2. Не дописывать и разместить. С комментариями, в каких случаях он падает.
3. Написать свой (если идею считаете полезной). Тем более, что Вы это сделали бы быстрее.
4. Забанить тему совсем. Этот вариант будет грустный, т.к. в "нормальных" условиях скрипт работает, и в некоторых случаях он бывает полезным. Могут найтись желающие поюзать.
Если будете что-то делать сами, насчёт авторских прав не парьтесь - мне эта тема не интересна, и за неё я денег получать не планирую. Хотя было бы приятно видеть в тексте что-нить типа "идея Буняка А.Х." :-)
5. Что-то иное...

Реализация Condensed View

Posted: Sun 26 Jul, 2015 15:50
by John Doe
buniak_a_h wrote: У меня - работает.
Хочется надеяться что при разработке таможенного софта вы придерживаетесь других принципов.

А работа есть у всех, и свои недописанные скрипты тоже.
Если вы более не намерены заниматься скриптом, то тема будет закрыта, да.
(Но не удалена, любой сможет доделать и выложить свою версию, в другой теме)

Реализация Condensed View

Posted: Sun 26 Jul, 2015 23:42
by buniak_a_h
John Doe wrote: Хочется надеяться что при разработке таможенного софта вы придерживаетесь других принципов
Главное - чтоб работало и не падало.
Короче, в последней (уже, видимо, не крайней) версии макроса сделано всё. Предусмотрены совсем уж гипотетические ситуации (типа перезагрузки макросов прямо во время работы, попытка отменить режим R/O в сжатом режиме, попытка сохранить файл...). Даже сохранение файла не по команде с клавиатуры, а как-то по-другому (у меня, в частности, макрос CtrlS вызывает сохранение). Так что тему можете закрывать.

Реализация Condensed View

Posted: Mon 27 Jul, 2015 23:06
by DrKnS