Существует ли когда-нибудь серьезное основание использовать оценку ()?
Проблема с вашей идеей в том, что ваша отсутствующая зависимость может иметь другие зависимости, и maven не может их узнать, прежде чем вы фактически сделаете этот артефакт доступным. Таким образом, полное решение невозможно. Частичное решение может зависеть от того, почему вы пропустили так много артефактов и как работает процедура фиксации.
У нас была ситуация, когда полный доступ к MavenCentral не был разрешен, и артефакты необходимо было скопировать из MavenCentral в хранилище компании. Я создал скрипт, который копировал артефакты вместе со всеми транзитивными зависимостями - таким образом я мог избежать большинства итеративных проблем «отсутствующих артефактов».
9 ответов
Да - когда нет другого способа выполнить данную задачу с разумным уровнем ясности и в пределах разумного количества строк кода.
Это исключает 99% случаев, когда используется eval, для всех языков и контекстов.
Написание классного учебного примера о том, как легко реализовать «калькулятор» на языке X? =)
Одно из разумных применений - это если у вас есть интерпретируемый язык, который вы построили поверх другого языка, но вы все еще хотите предоставить своего рода «аварийный штрих», чтобы люди могли вернуться к функциям, которые предоставляет основной язык. Одним из примеров является реализация Пролога на Лиспе, а затем определение предиката, который позволяет прямое использование функций Лисп через EVAL.
Я использовал его один раз при тестировании сайта - мы написали небольшой скрипт php, который расшифровывает и выполняет криптографически подписанные полезные данные из незарегистрированных источников данных HTTP на лету. Это лучшее использование eval (), которое я когда-либо видел.
(Другими словами: нет, я никогда не видел хорошего применения eval)
eval часто является наиболее целесообразным решением в ситуациях, когда вы динамически генерируете код. Даже в языках, которые официально не поддерживают eval, таких как Java, они поддерживают отражение и модификацию классов во время выполнения, которые аналогичны. (См. Такие книги, как Разработка компонентов для платформы Java Стю Хэллоуэя)
Может быть, я слишком много использую sh и perl , но я никогда не видел, чтобы кто-нибудь относился к eval с помощью презрение, которое получает goto .
Итак, мой ответ: « eval подходит, когда вы пишете perl 5 и sh ». Блок eval является основным механизмом try / catch в Perl , и без него сложно написать безопасный код.
Для быстрых взломов нет проблем, потому что это удобный способ быстрого выхода.
В производственном коде считайте это крайней мерой - и даже тогда попробуйте что-нибудь еще, потому что eval трудно контролировать и, следовательно, опасно. Для чего-нибудь нетривиального реализуйте подъязык.
Наугад: eval хорош для реализации компилятора выражений для бедняков и тому подобного. К тому же это унылая ржавая замена гигиеническим макросам.
Для отладки / тестирования идеи перед ее правильным воплощением.
Например, вы делаете игрушечный калькулятор и хотите сначала поработать с графическим интерфейсом, поэтому вы просто используете eval для выполнения "внутренней" работы в фоновом режиме. Позже вы вернетесь к бэкэнду, поцарапаете eval и напишете правильный синтаксический анализатор выражения.
eval для выполнения "внутренней" работы в фоновом режиме. Позже вы вернетесь к бэкэнду, поцарапаете eval и напишете правильный синтаксический анализатор выражений. так что вы просто используете eval для выполнения "внутренней" работы в фоновом режиме. Позже вы вернетесь к бэкэнду, поцарапаете eval и напишете правильный синтаксический анализатор выражения.