@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Проще создайте перед циклом две переменных с значением 0, и внутри каждого цикла первым действием увеличивайте отдельную переменную. В такой конструкции не будет неожиданностей с переопределением.
Тут есть небольшая проблема.
Если в кастомном модуле в функции есть цикл, то код из кастомного модуля затрет переменную CYCLE_INDEX в коде пользовательского скрипта своим значением.
С другими подобными переменными такая же проблема.
Вероятно, надо в коде функции кастомного скрипта перед объявлением цикла проверять есть ли такая переменная(она может быть объявлена в коде пользовательского скрипта), если есть, то сохранять ее и восстанавливать значение до возврата из функции.
Причем нужно восстанавливать значение при любом поведении, в том числе если функция из модуля упадет, чтобы пользователь не увидел свои изменённые переменные и долго не думал "что за фигня тут у меня".
Это если пользователь решит обернуть вызов функции из модуля в ошибку.Выглядит жутким хаком.
Проблема переменных BAS в модулях имеют более глобальные последствия, ведь многие используют в действиях стандартные названия переменных, а затем из этих действий создают модули, которые и вызывают проблемы перезаписи переменных со стандартными названиями. Об этой проблеме уже есть тикет, есть несколько возможных решений, но пока единственный надёжный способ, это в ручную править код заменяя переменные BAS на переменные js (var VAR_CYCLE_INDEX и т.д.)
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
проблема переменных BAS в модулях имеют более глобальные последствия
Да. Но основная проблема не в существующем поведении, а в том, что нет документации на этот счет, пользователи расшибают лбы об стенку самостоятельно.
И нет инструкция с обходными путями. Пользователи сами придумывают костыли, как избежать этого.
Хотя логика простая - если до вызова функции некий список переменных был объявлен(CYCLE_INDEX, VAR_FOREACH_DATA, etc), то перед вызовом функции сохранять их значения и восстанавливать после возврата.
Вот прямо сейчас я это и делаю на основании твоего же кода.
P.S.
У модулей должен быть своя видимость области переменных, это решит почти все проблемы.
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
проблема переменных BAS в модулях имеют более глобальные последствия
Да. Но основная проблема не в существующем поведении, а в том, что нет документации на этот счет, пользователи расшибают лбы об стенку самостоятельно.
И нет инструкция с обходными путями. Пользователи сами придумывают костыли, как избежать этого.
Хотя логика простая - если до вызова функции некий список переменных был объявлен(CYCLE_INDEX, VAR_FOREACH_DATA, etc), то перед вызовом функции сохранять их значения и восстанавливать после возврата.
Вот прямо сейчас я это и делаю на основании твоего же кода.
P.S.
У модулей должен быть своя видимость области переменных, это решит почти все проблемы.
Не уверен, что область видимости можно ограничить в BAS. Можно поступить с переменными, как с функциями - добавить опцию, что бы генерировать длинные случайные названия переменных, заменяя используемые в функции при создании модуля
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Не уверен, что область видимости можно ограничить в BAS
Пользователям нельзя, разработчику думаю можно все.
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Можно поступить с переменными, как с функциями - добавить опцию, что бы генерировать длинные случайные названия переменных
Кстати идея, задумался не написать ли мне сейчас скрипт, который делает post-process модуля, превращая все переменные внутри функции модуля в случайные названия.
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Пользователям нельзя, разработчику думаю можно все.
Если реализация изоляции переменных BAS в модуле будет требовать больших изменений в текущей логики работы BAS, то разработчик этого делать не будет.
Кстати идея, задумался не написать ли мне сейчас скрипт, который делает post-process модуля, превращая все переменные внутри функции модуля в случайные названия.
Да, я вроде даже выкладывал скрипт для замены имён переменных в модуле, не помню только где именно.
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Да, я вроде даже выкладывал скрипт для замены имён переменных в модуле, не помню только где именно.
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
это в ручную править код заменяя переменные BAS на переменные js (var VAR_CYCLE_INDEX и т.д.)
Если в файле engine.js заменить все переменные, которые начинаются с VAR на что-то другое, то это пройдет без побочных эффектов?
было:
VAR_LOG_PREFIX = _function_argument("_log_prefix")
var json = JSON.parse(native("filesystem", "fileinfo", VAR__DIRECTORY_PATH))
VAR_FILEINFO_EXISTS = json["exists"]
стало:
_LOG_PREFIX = _function_argument("_log_prefix")
var json = JSON.parse(native("filesystem", "fileinfo", __DIRECTORY_PATH))
_FILEINFO_EXISTS = json["exists"]
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
это в ручную править код заменяя переменные BAS на переменные js (var VAR_CYCLE_INDEX и т.д.)
Если в файле engine.js заменить все переменные, которые начинаются с VAR на что-то другое, то это пройдет без побочных эффектов?
было:
VAR_LOG_PREFIX = _function_argument("_log_prefix") var json = JSON.parse(native("filesystem", "fileinfo", VAR__DIRECTORY_PATH)) VAR_FILEINFO_EXISTS = json["exists"]стало:
_LOG_PREFIX = _function_argument("_log_prefix") var json = JSON.parse(native("filesystem", "fileinfo", __DIRECTORY_PATH)) _FILEINFO_EXISTS = json["exists"]
По идее должно работать, однако вы меняете одни глобальные переменные js на другие.
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
По идее должно работать, однако вы меняете одни глобальные переменные js на другие.
Было "VAR_", стало без него.
А это значит, что стандартным способом пользователь не сможет случайно затереть свою переменную из-за модуля, которую он также создал стандартным способом(BAS-переменная).
Или надо var VAR_Buu и таким обзором они станут локальными javascript переменными ?
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
По идее должно работать, однако вы меняете одни глобальные переменные js на другие.
Было "VAR_", стало без него.
А это значит, что стандартным способом пользователь не сможет случайно затереть свою переменную из-за модуля, которую он также создал стандартным способом(BAS-переменная).
Я об этом и говорю, смысл в том, что к переменным модуля можно будет получить доступ извне. Если цель обезопасить пользователя от замены существующих переменных, то достаточно добавить длинную случайную строку (можно unixtime для уникальности добавить). Это будет более безопасно, чем удолять VAR_
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Я об этом и говорю, смысл в том, что к переменным модуля можно будет получить доступ извне. Если цель обезопасить пользователя от замены существующих переменных, то достаточно добавить длинную случайную строку (можно unixtime для уникальности добавить)
На всякий случай уточняю еще раз.
Было:
VAR_LOG_PREFIX = _function_argument("_log_prefix")
Стало:
Вариант 1:
var VAR_LOG_PREFIX = _function_argument("_log_prefix")
Вариант 2:
VAR_LOG_PREFIX_some_string_name_of_module_for_example = _function_argument("_log_prefix")
Вариант 3:
var VAR_LOG_PREFIX_some_string_name_of_module_for_example = _function_argument("_log_prefix")
По идее, второй вариант можно встроить в генератор модулей.
Тогда у пользователя останется возможность даже обратится к переменной модуля, если он захочет.
И в git не будут светиться лишние изменения, так как нет ничего случайного и нет мусорных diff.
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
По идее, второй вариант можно встроить в генератор модулей.
Тогда у пользователя останется возможность даже обратится к переменной модуля, если он захочет.
И в git не будут светиться лишние изменения, так как нет ничего случайного и нет мусорных diff.
Да
@Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
По идее, второй вариант можно встроить в генератор модулей.
Тогда у пользователя останется возможность даже обратится к переменной модуля, если он захочет.
И в git не будут светиться лишние изменения, так как нет ничего случайного и нет мусорных diff.Да
Так я и сделаю у себя, пока напишу скрипт для замены.
Огромное спасибо, что подсказал все варианты, что могут быть.
@sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:
Так я и сделаю у себя, пока напишу скрипт для замены.
Скрипт оказался мега-простой, замена в одну строчку, пропускаю код, где подготавливаются переменные:
module_replace_vars:
@echo "Replacing variables in engine.js for $(MODULE)..."
@sed -i 's/\(VAR_[A-Z_]\+\)/\1__$(MODULE)/g' "$(MODULE_DST_DIR)/$(MODULE)/$(MODULE)/engine.js"
@echo "Variable replacement complete for $(MODULE)."
Запускаю как:
make module_replace_vars MODULE=MyModule1
make module_replace_vars MODULE=MyModule2
Результат работы:
Выяснилось, что в кубике Browser / Javascript не поддерживаются переменные вида:
[[SomeCamelCase]]
А только вида:
[[FORTRAN_CASE]]
Соответственно нужно заменять переменные не на NameOfModule, а на NAME_OF_MODULE.
Иначе получаем ошибку в кубике Browser / Javascript :
ReferenceError: SERP_DATA__MyModule is not defined
Ну и надо некоторые служебные переменные исключить из замены.
Итого я заменяю так:
# Function to convert to screaming(BAS) snake case
define to_screaming_snake
$(shell echo $(1) | sed -E 's/([^A-Z])([A-Z])/\1_\2/g' | tr '[:lower:]' '[:upper:]')
endef
module_replace_vars:
@echo "Replacing variables in engine.js for $(MODULE)..."
@sed -i 's/\(VAR_[A-Z_]\+\)/\1__$(MODULE_SNAKE_CASE)/g' "$(MODULE_DST_DIR)/$(MODULE)/$(MODULE)/engine.js"
@sed -i 's/\([[\([A-Z_]\+\)]]\)/[[\2__$(MODULE_SNAKE_CASE)]]/g' "$(MODULE_DST_DIR)/$(MODULE)/$(MODULE)/engine.js"
@sed -i 's/VAR_LAST_ERROR__$(MODULE_SNAKE_CASE)/VAR_LAST_ERROR/g' "$(MODULE_DST_DIR)/$(MODULE)/$(MODULE)/engine.js"
@sed -i 's/VAR_ERROR_ID__$(MODULE_SNAKE_CASE)/VAR_ERROR_ID/g' "$(MODULE_DST_DIR)/$(MODULE)/$(MODULE)/engine.js"
@sed -i 's/VAR_WAS_ERROR__$(MODULE_SNAKE_CASE)/VAR_WAS_ERROR/g' "$(MODULE_DST_DIR)/$(MODULE)/$(MODULE)/engine.js"
@echo "Variable replacement complete for $(MODULE)."
# Call module_prepare_vars before module_replace_vars in the dependency chain
module_replace_vars: module_prepare_vars
# Prepare the module name variable
module_prepare_vars:
$(eval MODULE_SNAKE_CASE := $(call to_screaming_snake,$(MODULE)))
@echo "Variable preparation complete for $(MODULE_SNAKE_CASE)."
