Созданы ли файлы MooseX:: Declare и MooseX:: Method:: Signatures?

Ответ 1

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

Производительность

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

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

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

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

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

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

UPDATE

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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

Если вам нравится MooseX:: Declare, но вы хотите выполнить функцию Method:: Signatures, попробуйте Method::Signatures::Modifiers.

Ответ 6

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

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

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

Возможно, стоит избавиться от аргумента Perl, смещающего ад.