Добавить механизм порталов в PM

[Космический Василий]

Наверняка уже были такие предложения и наверняка у подобных систем есть более точный термин для такого, но всё равно создам тему так как такого функционала очень не хватает.
Короче нужна альтернатива ниточкам в PMe чем-то похожая на существующий good/bad end, чтобы, допустим, можно было определить блок кубиков, выполнить этот блок из любого места в проекте и пойти дальше. Например, представьте что у вас проект из сотен кубиков и на каждом десятом кубике потенциально надо решать капчу, сейчас в таком случае или всю логику решения капчи нужно переносить в общий код или дублировать кубики или городить клубок из ниток, у каждого из вариантов куча минусов, у варианта с порталами в таком случае минусов бы не было вообще, это было бы и удобно и красиво.

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

 

[samsonnn]

Нет не нужно такое! То что вы предлагаете это называется goto - при не правильном использовании вызывает хаос, и не понимание читать, отлаживать код. Да, звучит с вашей стороны супер, типа каждому действию кубика присвоить свой уникальный id и потом с помощью goto осуществлять прыжки к выбранному id. Но на практике, если прыжков много - это запутанность, полный хаос и неразбериха. Вам кажется что это для вас облегчит жизнь, но на самом деле это не так, а остальным наоборот ее усложнит. Особенно тех поддержке, когда будут новички писать что у них что то не работает и не выполняется, а виной будет именно флаг goto. Мой вам совет, пересмотрите логику вашего шаблона. Переосмыслите ее полностью. Поверьте в зенке goto не нужен вообще, иначе это будет жесть, жопа полная.

 

[Космический Василий]

при не правильном использовании вызывает хаос, и не понимание читать, отлаживать код.

Ну так про что угодно можно сказать

типа каждому действию кубика присвоить свой уникальный id и потом с помощью goto осуществлять прыжки к выбранному id.
Поверьте в зенке goto не нужен вообще, иначе это будет жесть, жопа полная.

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

 

[Carty]

иначе это будет жесть, жопа полная

Там и сейчас жесть и жопа полная, если требуется минимально сложный проект. Эти "порталы" это не goto, а обычные функции из прогрммирования. Вызвал определенный блок кубиков, он отработал и вернул управление в место где произошел вызов, опционально вернув результат. Где-то кто-то из разработчиков отвечал, что забыл реализовать такой функционал еще в далекие времена. Сейчас думаю такое уже не реализуют в 7 версии

 

[kotouser2024]

Читал по этой теме в старых обсуждениях, насколько помню, там этот приравнивалось к добавлению механизма goto и саппорт отмел это на корню.
Склонен согласиться, лучше уж иметь паутину стрелок, чем ходить по проекту и вычитывать куда должно перейти управление.

 

[Космический Василий]

Читал по этой теме в старых обсуждениях, насколько помню, там этот приравнивалось к добавлению механизма goto и саппорт отмел это на корню.
Склонен согласиться, лучше уж иметь паутину стрелок, чем ходить по проекту и вычитывать куда должно перейти управление.

Так а в чём тут, собственно, проблема если это и так уже реализовано в виде проекта в проекте/плагина

 

[Космический Василий]

Вообще конечно если просто перепрыгивать из одной части проекта в другой - такое действительно может вызвать проблемы при неправильном использовании, хотя я и не вижу причин почему такое не добавлять в зену.
Но я выступаю не за это, то бишь не за goto, а за функции, как уже было сказано выше - вызвать кубиком функцию в виде блока/блоков кубиков, которые с остальным проектом никак не связаны, выполнили её, пошли дальше, ну нету у такого варианта минусов

 

[AlayMint]

Вообще конечно если просто перепрыгивать из одной части проекта в другой - такое действительно может вызвать проблемы при неправильном использовании, хотя я и не вижу причин почему такое не добавлять в зену.
Но я выступаю не за это, то бишь не за goto, а за функции, как уже было сказано выше - вызвать кубиком функцию в виде блока/блоков кубиков, которые с остальным проектом никак не связаны, выполнили её, пошли дальше, ну нету у такого варианта минусов

Нам нужно объединиться и назваться «Свидетели GOTO»

 

[Carty]

Если вдваваться в рассуждения, то стрелка это и есть своего рода goto. Я за полную отмену стрелок! Только последовтельно идущие блоки/кубики!

 

[AntonBust]

Нет не нужно такое! То что вы предлагаете это называется goto - при не правильном использовании вызывает хаос, и не понимание читать, отлаживать код. Да, звучит с вашей стороны супер, типа каждому действию кубика присвоить свой уникальный id и потом с помощью goto осуществлять прыжки к выбранному id. Но на практике, если прыжков много - это запутанность, полный хаос и неразбериха. Вам кажется что это для вас облегчит жизнь, но на самом деле это не так, а остальным наоборот ее усложнит. Особенно тех поддержке, когда будут новички писать что у них что то не работает и не выполняется, а виной будет именно флаг goto. Мой вам совет, пересмотрите логику вашего шаблона. Переосмыслите ее полностью. Поверьте в зенке goto не нужен вообще, иначе это будет жесть, жопа полная.

Читал по этой теме в старых обсуждениях, насколько помню, там этот приравнивалось к добавлению механизма goto и саппорт отмел это на корню.
Склонен согласиться, лучше уж иметь паутину стрелок, чем ходить по проекту и вычитывать куда должно перейти управление.

Так можно же просто не использовать конструкцию "goto" если боитесь хаоса в своём проекте. Кому удобно, тот будет пользоваться, и наоборот.
goto существует в тех же си-подобных языках много десятков лет и хауса не наблюдается)

 

[Чешир]

Есть проект в проекте, гоуту не нужен

Если вдваваться в рассуждения, то стрелка это и есть своего рода goto. Я за полную отмену стрелок! Только последовтельно идущие блоки/кубики!

Так это тебе нужно в "аналогичную программу"

 

[izubr]

А мне очень понравилось второе предложение:
"Ещё не хватает кнопки защиты интерфейса от изменений в PMе, чтобы нажал и никакие окна больше никуда не сдвигаются, не растягиваются "
+++
Например бесит что каждый запуск PM в окне переменных поле "Значение по умолчанию" такой же ширины как и основное поле со значением переменных.

 

[AlayMint]

А мне очень понравилось второе предложение:
"Ещё не хватает кнопки защиты интерфейса от изменений в PMе, чтобы нажал и никакие окна больше никуда не сдвигаются, не растягиваются "
+++
Например бесит что каждый запуск PM в окне переменных поле "Значение по умолчанию" такой же ширины как и основное поле со значением переменных.

@Космический Василий, кстати, его бы вынести в отдельное предложение.

 

[kotouser2024]

Так можно же просто не использовать конструкцию "goto" если боитесь хаоса в своём проекте. Кому удобно, тот будет пользоваться, и наоборот.
goto существует в тех же си-подобных языках много десятков лет и хауса не наблюдается)

Я думаю, что ради того, "чтобы было", не стоит тратить время на это.
Есть наверняка более критические моменты, которые нужно исправлять.

 

[kotouser2024]

Так а в чём тут, собственно, проблема если это и так уже реализовано в виде проекта в проекте/плагина

Ну да. Альтернатива есть, почему бы не пользоваться подпроектами.
Тех которым нужны goto - думаю, что не так много.

 

[tsup]

На удивление не соглашусь с большинством и соглашусь с ТС. Этой фичи очень не хватает, если пользователь-новичок делает крупные проекты и не знает C#.

То что вы предлагаете это называется goto

Предлагается, насколько я понял, аналог функции. Теоретический аналог goto - как раз стрелки.

каждому действию кубика присвоить свой уникальный id и потом с помощью goto осуществлять прыжки к выбранному id. Но на практике, если прыжков много - это запутанность, полный хаос и неразбериха.

Это точно не применимо к функциям. Зато отлично применимо к тем самым стрелкам в огромных проектах.
Пример: вы разрабатываете что угодно, что имеет подключение к нейронке. У вас где-то есть написанный (на блоках, конечно: предположим вы новичок, и не знаете C#) обработчик запросов и ответов к нейронке. И в процессе развития проекта у вас мало того, что появляются сотни стрелок к этому блоку, так ещё и работает это реально как goto: на выходе из обработчика у вас скорее всего стоит switch на проверку, откуда был вызов, чтобы вернуться обратно.
В итоге за пару дней разработки проект на блоках начинает выглядеть примерно так:



Если вам не стало страшно от этого скриншота, то вы скорее всего не пытались обслуживать подобный проект
Как думаете, что произойдёт через месяц, год такой "разработки"?

Есть проект в проекте

У которого куча минусов. Усложнённый перенос проекта на другой ПК, +$2 за каждый подпроект при каждой продаже (я понимаю, что разработчикам ZP деньги тоже нужны, но это допустимо, когда таких подпроектов 5-10, а при нормальном их использовании уже на среднем проекте их будет больше. Из-за чего на коммерческих шаблонах, собственно, почти и не используют "проект в проекте", т.е. разработчики ZP и так вряд-ли зарабатывают ощутимые средства с этого, по сравнению с миграцией крупных проектов с ZP на самописные вайбкод-решения), сложность отладки ошибок внутри подпроектов, сложность в принципе использования такого функционала.