Готовы ли MooseX :: Declare и MooseX :: Method :: Signatures к производству?

Question

Из текущей версии (0.98) из Moose :: Manual :: MooseX - строки:

Мы возлагаем большие надежды на будущее MooseX::Method::Signatures и MooseX::Declare. Однако эти модули, при этом регулярно используются в производство некоторыми из более безумных члены сообщества, до сих пор отмечена альфа на всякий случай задом наперед необходимо внести несовместимые изменения.

Я заметил, что для MooseX::Method::Signatures в журнале изменений за сентябрь 2009 года упоминается удаление " страшного отказа от ответственности ALPHA ".
Итак, это все еще "альфа"?
Буду ли я все еще считаться одним из "более безумных", чтобы использовать их?

Answer 1

Я бы сказал, что они готовы к производству - я использую их в производстве - но есть несколько вещей, которые следует учитывать:

Performance

MooseX::Declare и зависимости делают почти всю свою магию во время компиляции. В зависимости от размера вашей программы, вы можете найти от полсекунды до нескольких секунд дополнительных издержек инициализации. Если это проблема, не используйте MooseX :: Declare .

Во время выполнения основная нагрузка - проверка типов и аргументов, которую вы должны (в идеале) делать в любом случае. Тем не менее, ограничения типа Moose имеют некоторые накладные расходы, а именно принуждение и более сложные ограничения (MooseX :: Types :: Structured-style). Не используйте их, если производительность является проблемой.

Стабильность

MooseX :: Declare и MooseX :: Method :: Signature внешний синтаксис теперь стабилен. Но важно знать, что внутренние органы подвержены крайним изменениям. (к счастью, меняется в лучшую сторону)

Чтобы дать вам представление, сама подпись захватывается с помощью большого блока кода C, украденного из токенайзера Perl (toke.c). Это может сломаться в некоторых ситуациях, так как на самом деле ничего не анализируется. Бит внутри скобок анализируется с использованием PPI , который предназначен для чистого Perl, но получающееся дерево PPI затем взламывается, чтобы получить что-то полезное. Devel :: Declare сам по себе является хаком - после того, как он видит конкретные ключевые слова (например, 'role', 'class', 'method'), модуль, использующий Devel :: Declare, должен переписать исходный код вручную, без взаимодействия с настоящим парсером Perl.

Угловые случаи могут стать причиной ошибки Perl. Или плохо переписать исходный код, чтобы вы получили синтаксические ошибки, но понятия не имеете, что их вызывает без -MO::Deparse. Если вы случайно испортили синтаксис MooseX :: Declare , то нет гарантии, что модуль обнаружит это и выдаст вам ощутимую ошибку. Сообщение ALPHA, возможно, ушло, но это все еще делает темных и страшных вещей внутри, и вы должны быть готовы к этому.

UPDATE

MooseX :: Declare сильно не обновлялся, и вы можете рассмотреть альтернативы, такие как Moops . Лично я решил придерживаться чистого Moose, пока сам Perl не начнет поддерживать класс / метод / имеет собственный синтаксис, который возможно на картах .

Answer 2

Я думаю, что это вопрос разных точек зрения - rafl - один из вышеупомянутых "более безумных членов сообщества", в то время как Rolsky более консервативен.Вам решать, с кем вы согласны, и на самом деле я думаю, что наиболее важной переменной является ваш собственный код.

MooseX :: Declare - хороший код.Он не будет случайным образом взрывать вашу машину, он не будет ужасен для производительности, и он предлагает много изящных вещей, уменьшая при этом количество шаблонов, которые вы должны написать.Но это может измениться в будущем, из-за чего ваш код откажется компилировать, пока он не обновится;это может привести в замешательство ваш редактор и другие инструменты разработки, когда он увидит синтаксис, который он не сможет проанализировать, может разозлить ваших соавторов, заставив их научиться новому модулю работать с вашим кодом, или может разозлить вашего босса, заставив егопоэтому любой будущий сопровождающий должен изучить новый модуль для работы с вашим кодом.Какие из этих вещей относятся к вам, и в какой степени?Надеюсь, ты знаешь лучше, чем я.

Answer 3

Есть люди, которые чувствуют, что зрелость и стабильность MooseX::Delcare, Devel::Declare, на которых он основан, или даже Moose, еще не готовы к «прайм-тайму». Я также знаю две крупные компании с миллионами посетителей в месяц, у которых MooseX::Declare в их производственной среде. Лично я доволен стеком, который мне предоставлен Moose, и пока не вижу необходимости вносить MooseX::Declare. Я знаю людей, мнение которых я глубоко уважаю, которые отказываются писать новый код без декларативного сахара из MooseX::Declare.

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

Answer 4

MooseX :: Method :: Signatures (MXMS) и MooseX :: Declare, которые его используют, не готовы к работе. Это не потому, что код не стабилен, а потому что он ужасно медленный. Простое использование ключевого слова method, без типов и аргументов, приводит к достижению производительности 500-1000x во время выполнения по сравнению с обычным вызовом метода . Мой Macbook Pro может выполнять около 6000 простых вызовов методов в секунду, используя MXMS против 5 000 000 с простым Perl.

Method :: Signatures , напротив, почти не достигает производительности, превышающей то, что обычно требуется для выполнения запрошенных проверок. Синтаксис почти такой же, как у MXMS, и он поддерживает типы Moose (и Mouse). Оба полагаются на один и тот же метод модификации синтаксиса. (Полное раскрытие, я автор метода :: Подписи.)

Если вам нравится MooseX :: Declare, но вы хотите производительность метода :: Подписи, попробуйте Метод :: Подписи :: Модификаторы .

Answer 5

Это зависит от того, что вы подразумеваете под «готовым производством». Я бы не зависел от них, пока их скорость не сильно замедлится. Мне нравится, что мои рабочие материалы не нуждаются в частом уходе от внешних изменений кода, настроек API и так далее. Это не что-то особенное для Муз, но любой молодой проект.

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

Answer 6

MooseX::Declare и MooseX::Method::Signatures работают хорошо, но могут иметь очень неприятные последствия в зависимости от того, что делает ваш код. Это можно исправить, просто не используя ключевое слово method или Method::Signatures::Modifiers.

Нарушение производительности, которое я вижу, составляет около 2-5x по сравнению с Method::Signatures::Modifiers (5x в основном для одного конкретного класса, который я использовал). И кажется, что это в основном время компиляции или, возможно, инициализация в первый раз, потому что он становится меньше 2х, когда вычисления длиннее.

Method::Signatures::Modifiers имеет лучшие ошибки, но вы должны отключить эту оптимизацию, когда используете отладчик (он выходит из строя, потому что он не видит эти методы, вы можете убедиться в выводе -MO=Deparse).

Может быть, стоит избавиться от адского сдвига аргумента Perl.