Я должен зарегистрироваться в *.mo файлах?

До версии 2.8 вам приходилось выбирать между пакетами и объектами. Проблема с пакетами заключается в том, что они не могут содержать методы или значения самостоятельно. Таким образом, вы должны поместить все это в другой объект, который может стать неловким. Обратите внимание:

object Encrypt {
  private val magicConstant = 0x12345678
  def encryptInt(i: Int) = i ^ magicConstant
  class EncryptIterator(ii: Iterator[Int]) extends Iterator[Int] {
    def hasNext = ii.hasNext
    def next = encryptInt(ii.next)
  }
}

Теперь вы можете import Encrypt._ и получить доступ к методу encryptInt, а также к классу EncryptIterator. Удобно!

Напротив,

package encrypt {
  object Encrypt {
    private[encrypt] val magicConstant = 0x12345678
    def encryptInt(i: Int) = i ^ magicConstant
  }
  class EncryptIterator(ii: Iterator[Int]) extends Iterator[Int] {
    def hasNext = ii.hasNext
    def next = Encrypt.encryptInt(ii.next)
  }
}

Это не огромная разница , но это заставляет пользователя импортировать как encrypt._, так и encrypt.Encrypt._ или должен сохранять писать Encrypt.encryptInt снова и снова. Почему бы просто не использовать объект вместо этого, как в первом шаблоне? (На самом деле нет никакого снижения производительности, поскольку вложенные классы на самом деле не являются внутренними классами Java; насколько это известно JVM, это просто обычные классы, но с причудливыми именами, которые говорят вам, что они вложенные.)

В 2.8 вы можете получить свой торт и съесть его: назовите вещь как объект пакета, и компилятор перезапишет код для вас, так что на самом деле он выглядит как второй пример под капотом (за исключением объекта Encrypt ] на самом деле называется package внутренне), но ведет себя как первый пример с точки зрения пространства имен - значения vals и def находятся тут же, без необходимости дополнительного импорта.

Таким образом, проекты, которые были начаты до 2.8, часто используют объекты, чтобы заключить в них множество вещей, как если бы они были пакетом. После 2.8 одна из основных мотиваций была удалена. (Но, чтобы быть ясным, использование объекта по-прежнему не повредит; более того, он концептуально вводит в заблуждение, а не отрицательно влияет на производительность или что-то в этом роде.)

(PS Пожалуйста, не пытайтесь фактически зашифровать что-либо таким образом, кроме как в качестве примера или шутки!)

17
задан muhuk 10 June 2009 в 09:52
поделиться

2 ответа

Общий ответ - не хранить сгенерированное содержимое в системе контроля версий.

Вы можете включить его в tarball, если для этого требуются редкие инструменты, или даже иметь отдельный репозиторий или отключенную ветку только с этими сгенерированными файлами (например, ветви 'html' и 'man' в репозитории git.git).

7
ответ дан 30 November 2019 в 13:40
поделиться

Общий ответ:
если вам действительно нужны эти файлы для компиляции или развертывания (на снимке: для «работы») вашего компонента (набора файлов, запрашиваемых из вашей VCS), то да, они должны храниться в нем (здесь: в Git).
То же самое и с другими типами файлов (например, файлы проекта )

.mo файлы являются конкретными:

django-admin.py compilemessages utility.

Этот инструмент запускает все доступные файлы .po и создает .mo файлы, которые являются бинарными файлами, оптимизированными для использования с помощью gettext

Значение:

  • вы должны иметь возможность перестраивать их каждый раз, когда они вам нужны (фактически гарантируя, что они синхронизированы со своими .po couterparts)
  • Git не так хорош с двоичным хранилищем, и это позволило бы избежать сохранения полной версии для каждого изменения

Так что конкретный ответ не так однозначен:

  • если ваши po-файлы являются стабильными и не будут развиваться слишком часто, вы можете окончательно сохранить файл .mo
  • , вам следует абсолютно сохранить большой файл README, объясняющий, как сгенерировать mo из файлов po.
14
ответ дан 30 November 2019 в 13:40
поделиться
Другие вопросы по тегам:

Похожие вопросы: