Смотрю тут отличные вопросы идут по !!re... У меня тоже появился, не могу понять смысл команды !!co - в справке указано:

Quote:!!co ("continue" – продолжить) с условием (опционально) немедленно переходит к ресиверу цикла !!en, который, в свою очередь, будет выполняться в соответствии с логикой работы.

И хочется сказать - и что? Ну переходит, разве это не логичное продолжение выполнения !!re? Он ведь так и так идёт до !!en... Или при срабатывании !!co не учитывается счётчик кругов? Есть более понятный пример про эту команду?

(15.10.2020 01:43)Berserker Wrote:  [*] SN:G is DEPRECATED and may be removed in future versions.

Кто ж в очередной раз захочет переписывать ERA-скрипты, использующие !!SN:G? Скорее всего опять скриптописатели разделятся на староверов и нововеров (а кто-то например ещё до сих пор сидит на ERA 2.46, а есть кто и под WoG 3.58 что-то мудрит...).

(15.10.2020 02:17)Bes Wrote:  во-о-т! наконец-то ты сказал то,что следовало сказать - нельзя прыгать в структурные блоки.

Теоретически можно, код только будет чуток посложнее (т.е. прыжок будет в подготовительную часть кода, в котором будут прописаны структурные границы, например !!en:; для выхода из !!re, ну и следующий прыжок уже куда нужно). Ну или прыгать прямо на !!en:;, где прописывать условия для мгновенного выхода из цикла.

А мне вот привычны стандартные DO...WHILE. Когда условие для проверки где пишется, там и проверяется. А не наоборот, как в !!re:;, от чего я не хочу использовать !!re:; и предпочитаю !!SN:G.

(15.10.2020 02:45)Night Wrote:  И хочется сказать - и что? Ну переходит, разве это не логичное продолжение выполнения !!re? Он ведь так и так идёт до !!en... Или при срабатывании !!co не учитывается счётчик кругов? Есть более понятный пример про эту команду?

Если скляроз не изменяет, !!co:; просто прыгает в начало цикла и +1 к итерации. Ну а !!br:; - выход из цикла. А нестандартные циклы можно создавать только с помощью !!SN:G и меток

(15.10.2020 02:58)XEPOMAHT Wrote:  

(15.10.2020 01:43)Berserker Wrote:  [*] SN:G is DEPRECATED and may be removed in future versions.

Кто ж в очередной раз захочет переписывать ERA-скрипты, использующие !!SN:G? Скорее всего опять скриптописатели разделятся на староверов и нововеров (а кто-то например до сих пор сидит на ERA 2.46).

Let's avoid making this same mistake again, please, because of these changes that instead of updating and making it backwards compatible, the code replaced by something new has consequences for the future of the community.

Bes, конечно, не будет.

Night, !!сo сразу же перешагивает в конец цикла, завершая текущую итерацию. После чего к переменной-счётчику прибавляется значение шага и идёт проверка на продолжение цикла. Аналог !!co:

Quote:Кто ж в очередной раз захочет переписывать ERA-скрипты, использующие !!SN:G?

DEPRECATED означает, что новые скрипты не нужно писать с этой командой. Старые будут работать.

Quote:DO...WHILE

Большинство циклов это WHILE DO, то есть с возможностью 0-я итераций. !!re позволяет писать любые, от FOR i FROM x TO y BY step до LOOP и DO WHILE.
V_Maiko, everything is fine, friend, no need to worry. I follow best practices of product evolutioning. Deprecating features means, that in 3.X Era versions it's not recommended to use some commands in new scripts anymore.

(15.10.2020 02:58)XEPOMAHT Wrote:  ... и предпочитаю !!SN:G.
Если скляроз не изменяет, !!co:; просто прыгает в начало цикла и +1 к итерации. Ну а !!br:; - выход из цикла. А нестандартные циклы можно создавать только с помощью !!SN:G и меток

Ага, и код в !!SN:G превращается в нечитаемую лапшу. XEPOMAHT, я понимаю, что ты привык писать на асме, и поэтому !!SN:G - это твой способ (асм весь в этом), но в высокоуровневом программировании это невероятно плохой тон написания кода. Не надо других (кто не владеет асмом) подписывать на дурные механики.

(15.10.2020 02:45)Night Wrote:  И хочется сказать - и что? Ну переходит, разве это не логичное продолжение выполнения !!re? Он ведь так и так идёт до !!en... Или при срабатывании !!co не учитывается счётчик кругов? Есть более понятный пример про эту команду?

Читайте про цикл for, который есть во всех языках программирования. Это самый простой и понятный цикл из всех возможных. Это базовые основы. Их важно знать!
Сам по себе цикл for простой до безобразия.

Цикл в C++, JavaScript
for (переменная; начало; условие; шаг) {
    // ... тело цикла ...
   ; continue - начать новую итерацию (без продолжения нижеидущего кода)
   ; break - завершить цикл полностью (выход из цикла)
}

Цикл в ERM
!!re переменная/начало/условие/шаг;
    // ... тело цикла ...
    !!co:; начать новую итерацию (без продолжения нижеидущего кода)
    !!br:; завершить цикл полностью (выход из цикла)
!!en:;

Пример:
Что тут сложного?

Напомню, что очень часто нужна итерация от 0 от Кол-Во чего-то -1, поскольку массивы индексируются с нуля. Или даже -2, если нужно исключить последний элемент из обработки. В таких случаях используем синтаксис из Эры 3.0.4:


!!re переменная/начальное значение/конечное значение/шаг/что прибавить к конечному значению
Читается данный код как FOR i FROM 0 TO arraySize - 1 DO.
То есть выполнять от 0 до (размер массива - 1, то есть индекса последнего элемента).

(15.10.2020 04:13)Berserker Wrote:  новые скрипты не нужно писать с этой командой. Старые будут работать.

Тогда не надо писать "removed in future versions", если предполагается всё же сохранить совместимость со старыми скриптами. Не пугайте народ.

(15.10.2020 11:22)igrik Wrote:  Ага, и код в !!SN:G превращается в нечитаемую лапшу.

Для меня в любом виде ERM - такая же слабочитаемая лапша, как и чистый ассемблер, если в коде напрочь отсутствуют комментарии или они на английском языке. Как впрочем и Си мне прочитать сложно в виду того, что не программист я, а только кодер.

Если использование !!SN:G откомментировано, то и читается и по прошествии 5 лет с момента написания кода нормально и понятно, по крайней мере для приверженца низкоуровнего программирования.

(15.10.2020 11:22)igrik Wrote:  Не надо других (кто не владеет асмом) подписывать на дурные механики.

Считаю, что если человек хочет программировать на высоком уровне, то он и должен конкретно изучать высокоуровневое программирование. Если хочет делать скрипты по принципам низкоуровнего языка - то использовать !!SN:G с умом. А если хочет делать "как получится" и "так сойдёт", как обычно получается у большинства скрипёров, то тут уже работает человеческий фактор: что-то проще сделать на !!re:;, ну а что-то и на !!SN:G, если !!re:; покажется слишком сложным или неудобным. Или наоборот.

Нельзя же всех скриптёров равнять на профессиональных программистов. Можно только рекомендовать не использовать в коде неудобные для программистов конструкции.

(15.10.2020 14:12)XEPOMAHT Wrote:  Для меня в любом виде ERM - такая же слабочитаемая лапша

Да, ERM1 это слабочитаемая лапша.
ERM2.0 это уже вполне читаемый код (конечно, если пользоваться именованиями).

(15.10.2020 14:12)XEPOMAHT Wrote:  Считаю, что если человек хочет программировать на высоком уровне, то он и должен конкретно изучать высокоуровневое программирование. Если хочет делать скрипты по принципам низкоуровнего языка - то использовать !!SN:G с умом. А если хочет делать "как получится" и "так сойдёт", как обычно получается у большинства скрипёров, то тут уже работает человеческий фактор: что-то проще сделать на !!re:;, ну а что-то и на !!SN:G, если !!re:; покажется слишком сложным или неудобным. Или наоборот.

Да, ты прав. Но в любом случае нужно стремиться к "правильному". Иначе у нас опять будет что-то наподобие "WoG Scripts", который написан через жопу.

XEPOMAHT, всё правильно пишу. Вредные или мешающие развитию конструкции, функции или элементы поведения сперва объявляются устаревшими, а в следующих мажорных версиях (4.Х) могут (есть вероятность) быть удалены. Такие формулировки я всегда использую по примеру других проектов. Это делается с тем, чтобы новые скрипты не использовали указанный функционал (и всегда можно сослаться на документацию с предупреждением), а в самых важных старых можно было сделать замену. Посмотри на эволюцию PHP, например. Она именно такая, плавная.

Quote:Для меня в любом виде ERM - такая же слабочитаемая лапша

Это личное уже. Я Феникс более десяти лет назад писал на ЕРМ + SCVS. Все именованные переменные и функции, макросы. И всё читаемо. Равно как и читаем код на ERM 2.0. Знание английского сейчас практически обязательное в кодинге, кроме 1С. Так код понимают люди из разных стран и регионов. Тут тоже ничего не поделаешь. Но писать можно для себя хоть на транслите.
!!VR(kolvoMonstrov):S(BAZOVOE_KOLVO_MONSTROV);

Потому я рекомендую новый код писать структурными блоками. Примеры решения ситуаций могу привести, если поставишь задачу.

(15.10.2020 14:08)Berserker Wrote:      !!re i/0/(numStacks)/1/-1:;
    ...
    !!en:;

Лично для меня более-менее идеальным было бы так:

while...do


do...while


Тогда и от !!SN:G в скриптах можно избавиться без особых напрягов.

(15.10.2020 14:26)igrik Wrote:  Иначе у нас опять будет что-то наподобие "WoG Scripts", который написан через жопу.

При том состоянии языка, в котором он был в 2001-2004 годы, по-другому вроде и не напишешь. Поэтому я и жду, когда ERM окончательно устаканится и можно будет со 100% уверенностью переписать все скрипты в нормальный вид без опасений их будущих отторжений в какой-нибудь ERA 4.0.

(15.10.2020 14:34)Berserker Wrote:  а в следующих мажорных версиях (4.Х) могут (есть вероятность) быть удалены. Такие формулировки я всегда использую по примеру других проектов. Это делается с тем, чтобы новые скрипты не использовали указанный функционал (и всегда можно сослаться на документацию с предупреждением), а в самых важных старых можно было сделать замену. Посмотри на эволюцию PHP, например. Она именно такая, плавная.

А заниматься обновлением скриптов, использующим старые erm-команды, кому придётся? Тут недавно обещали, что в ERA 3 на эволюции ERM наконец-то будет поставлена точка. Или всё-таки ждать ERA 4, в которой и будет итоговый набор erm-команд и триггеров, который уже никогда не поменяется?

(15.10.2020 14:34)Berserker Wrote:  Все именованные переменные и функции, макросы. И всё читаемо. Равно как и читаем код на ERM 2.0.

Помню, лет 5 назад скопировал несколько опций из ФМ в ERA+, которые потом пришлось методом научного тыка заставлять работать вне ФМ, т.к. была куча неявных зависимостей и так наскоком сложно было понять что-куда-зачем-почему (т.к. по каждой команде приходилось ворошить erm-хелп, а это считай что разбирать код вручную, что тогда это было легко читаемо для меня - не сказал бы так, скорее наоборот - код ФМ всячески ставил меня тогда в тупик, т.к. опыта в ERM тогда было очень мало).

(15.10.2020 14:34)Berserker Wrote:  Но писать можно для себя хоть на транслите.

Транслит - зло. Тот же WERD наполовину на кириллице, в ERM так же предпочитаю кириллицу.

Quote:А заниматься обновлением скриптов, использующим старые erm-команды, кому придётся? Тут недавно обещали, что в ERA 3 на эволюции ERM наконец-то будет поставлена точка. Или всё-таки ждать ERA 4, в которой и будет итоговый набор erm-команд и триггеров, который уже никогда не поменяется?

Обновлений ЕРМ не планирую существенных, но формулировки в документации оставлю и настаиваю, чтобы Бес это отразил в руководстве, чтобы новых SN:G неофитов не было

Quote:Помню, лет 5 назад скопировал несколько опций из ФМ в ERA+,

Я неудачно отформатировал жёсткий диск и потерял исходники. После чего вынужден был из сжатой каши кода всё восстанавливать. Увы.

Quote:Транслит - зло.

На ERM 2 строгие правила для идентификаторов функций, констант и локальных переменных. a-zA-Z0-9 + для констант и функций _.

(15.10.2020 17:11)Berserker Wrote:  

XEPOMAHT Wrote:Тут недавно обещали, что в ERA 3 на эволюции ERM наконец-то будет поставлена точка. Или всё-таки ждать ERA 4, в которой и будет итоговый набор erm-команд и триггеров, который уже никогда не поменяется?

Обновлений ЕРМ не планирую существенных, но формулировки в документации оставлю и настаиваю, чтобы Бес это отразил в руководстве, чтобы новых SN:G неофитов не было

одна загвоздка... Бесу команда SN:G вполне импонирует и чёт он совсем не хочет её хоронить формулировками от разраба. Я даж по секрету скажу, я добавил FU(OnRemoteEvent) в описаниях, но с аттрибутом на абзаце "display:hidden" и скрытым местом клика с действием 'visible'. Ибо негоже скрывать некие "небезопасные" плюшки от людей (как это было с тем же XX:Z)

Если добавлять в документацию детали реализации, которые должны быть скрыты, то тогда и справедливо получать в лоб от условного Валерия, который поверил такой документации или использовал неподдерживаемую в будущих версиях особенность реализации. Доберусь я до тебя ещё