Moose против MooseX:: Объявить

постлюдия

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

ОРИГИНАЛ

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

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

Ответы

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

Если вам не нужен синтаксический сахар MooseX, не используйте его. В зависимости от задачи, в которую вы работаете, я бы использовал ее "сверху вниз", например. 1. Мышь + Меход:: Подписи 2. Лось 3. то, возможно, MooseX

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

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

Ответ 4

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