Moose vs. MooseX :: Объявить

Question

постлюдия

MooseX :: Declare больше не будет рекомендоваться кем-либо, поскольку он использует Devel :: Declare, который выполнил свою задачу, но сам по себе устарел. На данный момент, если кто-то хочет MX :: D, он должен посмотреть на Moops

ORIGINAL

Предполагая, что у меня уже есть приличные знания о Perl OO в старом стиле, и предполагая, что я собираюсь написать какой-то новый код в какой-то разновидности Moose (да, я понимаю, что есть снижение производительности), мне было интересно, если глубже Я хочу пожелать, чтобы я выбрал другой путь? Не могли бы вы, Монахи, просветить меня относительными достоинствами Moose против MooseX::Declare (или какими-то другими?). Кроме того, насколько они взаимозаменяемы, один для одного класса, а другой для другого, если я решу переключиться.

(с. Я был бы согласен ответить на этот вопрос, однако я думаю, что правильно сформулированный ответ мог бы избежать субъективности)

Answer 1

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

Говоря как человек, который пользуется синтаксисом MooseX :: Declare, но все же предпочитает писать весь мой код на простом Moose, компромиссы в основном связаны с разработкой и поддержкой.

Основной список заметок при их сравнении:

• MooseX :: Declare имеет намного более краткий синтаксис. Вещи, которые занимают несколько сотен строк в простых старых объектах perl (POPO?), Могут занимать 50 строк в Moose, могут занимать 30 строк в MooseX :: Declare. Код из MooseX :: Declare для меня также более читабелен и элегантен.

• MooseX :: Declare означает, что у вас есть MooseX :: Types и MooseX :: Method :: Signatures бесплатно. Это приводит к очень элегантному синтаксису method foo(Bar $bar, Baz $baz) { ... }, который заставляет людей возвращаться в Perl после нескольких лет работы в Ruby.

• Недостатком MooseX :: Declare является то, что некоторые сообщения об ошибках намного более загадочны, чем Moose. Ошибка сбоя проверки TypeConstraint может произойти на нескольких уровнях глубоко в MooseX :: Types :: Structured, и оттуда, где вы сломали свой код, может быть трудно для людей, плохо знакомых с системой. У лося тоже есть эта проблема, но в меньшей степени.

• Места, где драконы прячутся в MooseX :: Declare, могут незначительно отличаться от того, где они прячутся в Moose. MooseX :: Declare пытается обойти известные проблемы Moose (например, время with()), но вводит некоторые новые места, о которых нужно знать. Например, MooseX :: Types имеет совершенно другой набор проблем, чем нативные типы Stringy Moose [^ 1].

• MooseX :: Declare имеет еще один удар по производительности. Это известно разработчикам MooseX :: Declare, и люди работают над этим (я полагаю, что для нескольких значений работы).

• MooseX :: Declare добавляет больше зависимостей в Moose. Я добавил этот, потому что люди уже жалуются на список зависимостей Moose, который составляет около 20 модулей. MooseX :: Declare добавляет еще 5 прямых зависимостей. Однако общий список согласно http://deps.cpantesters.org/ составляет Moose 27, MooseX :: Declare 91.

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

Надеюсь, это поможет ответить на вопрос.

[^ 1]: Некоторые говорят меньше, другие говорят больше. Честно говоря, разработчики ядра Moose все еще спорят об этом, и нет правильного ответа.

Answer 2

Один незначительный аспект, который может вас заинтересовать, и я также могу быть заинтересован ответом на него: главная проблема, с которой я столкнулся с MooseX :: Declare, которая была важна в моем конкретном случае, заключалась в том, что я не смог упаковатьмое приложение как исполняемый файл, ни с PAR :: Packer, ни с ActiveState PerlApp.

Затем я использовал https://github.com/komarov/undeclare/blob/master/undeclare.pl, чтобы вернуться к коду Moose.

Answer 3

Если вы действительно хотите Moose, рассмотрите подход снизу вверх, начинающийся с меньшего количества сахара.Я предпочитаю сначала использовать Mouse + Method :: Signatures.Мой сценарий состоит в том, что я сижу на бэкэнде, где нам нужно очень мало объектов, поверхностная иерархия, но иногда быстрые средства доступа - тогда мы все равно можем вернуться к XSAccessor.Мышь + Подпись метода, кажется, довольно хороший компромисс между синтаксической помощью и скоростью.Если мой дизайн действительно нуждается в большем, просто перейдите на Moose.Я могу подтвердить снижение скорости с помощью MooseX :: Declare не только с помощью простых тестов доступа (https://metacpan.org/pod/App::Benchmark::Accessors), но и в реальных приложениях.Это в сочетании с загадочными сообщениями об ошибках правил MooseX :: Declare out.

Answer 4

Как написано выше, другие проблемы с MooseX :: Declare: - ужасные сообщения об ошибках (действительно, бесполезные. Если вы не используете Method :: Signatures :: Modifiers) - снижение производительности (как вы заметили), но, на мой взгляд, не маленькое,(мы представили несколько больших реальных приложений) - проблема с TryCatch (если U использует это, см .: https://rt.cpan.org/Public/Bug/Display.html?id=82618) - некоторые несовместимости в смешанном (MooseX - не-Moose окружение, например, неудачная проверка $ VERSION)

Если вам не нужен «синтаксический сахар» MooseX, не используйте его.В зависимости от задачи, которую вы выполняете, я бы использовал «снизу вверх», например.1. Mouse + Mehod :: Signatures 2. Moose 3. затем возможно MooseX

в зависимости от того, что вы хотите.

Обновление не слишком сложно в этом порядке.Тем не менее, если вы дойдете до того, что вам действительно нужен MooseX, я бы скорее предложил вам поискать какой-то другой, разработанный специально для ОО язык, который предлагает большинство встроенных функций (например, horribile dictu Ruby или Python), ите, которые не найдены, вы, возможно, вы можете жить без.