Где экземпляры QuickCheck принадлежат к пакету для каббала?

У меня есть пакет cabal, который экспортирует тип NBT, которые могут быть полезны для других разработчиков. Я столкнулся с проблемой определения экземпляра Arbitrary для моего типа, и было бы позором не предлагать его другим разработчикам для тестирования своего кода, который объединяет мою работу.

Однако я хочу избежать ситуаций, когда мой экземпляр может мешать. Возможно, у другого разработчика есть другая идея для того, чем должен быть экземпляр Arbitrary. Возможно, моя зависимость пакета от конкретной версии QuickCheck может помешать или быть нежелательной в зависимостях клиентского проекта.

Мои идеи, в определенном порядке, следующие:

  • Оставьте экземпляр Arbitrary рядом с определением типа и позвольте клиентам справляться с затенением экземпляра или переопределением номера версии QuickCheck.
  • Сделайте экземпляр Arbitrary экземпляром-сиротой в отдельном модуле в одном пакете, скажем Data.NBT.Arbitrary. Зависимость от QuickCheck для всего пакета остается.
  • Предложите экземпляр Arbitrary в полностью отдельном пакете, чтобы он мог быть указан как отдельная тестовая зависимость для клиентских проектов.
  • Условно включают как экземпляр Arbitrary, так и зависимость QuickCheck в основном пакете, но только если установлен флаг типа -ftest.

Я видел комбинации всех из них, которые использовались в других библиотеках, но не нашел консенсуса, по которому лучше всего работает. Я хочу попробовать и получить его прямо перед загрузкой в ​​Hackage.

ОТВЕТЫ

Ответ 1

Проблема сводится к: насколько вероятно, что кто-то, использующий вашу библиотеку, захочет запустить тесты QuickCheck с помощью типа NBT?

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

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

Я не поклонник наличия пакетов QuickCheck в целом, хотя это может быть полезно в некоторых ситуациях.

Ответ 2

Исходя из не особого опыта, а общего стремления к надежности, руководящим принципом для зависимостей пакетов должно быть

От каждого в зависимости от их способности; каждому в соответствии с их потребностями.

Хорошо поддерживать зависимости пакета до минимума, необходимого для его существенной функциональности. Это предлагает вариант 3 или вариант 4 для меня. Конечно, это боль, чтобы набить пакет так много. Если параметры способны выразить обусловленность, то вариант 4 звучит как разумный подход, основанный на эффективном использовании языка, чтобы сказать, что вы имеете в виду.

Было бы здорово, если бы возникло мнение о том, какой один переключатель нам нужно щелкнуть, чтобы получить комплект для тестирования, а также основные функции.

Также ясно, что здесь есть место для уточнения. Удивительно, что Cabal работает так же хорошо, как и он, но это может позволить более сложные понятия "пакет", возможно, по типу системы модулей SML. Переведя зависимости в типы функций, мы в основном получаем запись

simplePackage :: (Dependency1, .., Dependencyn) -> Deliverable

но можно было представить более сложные комбинации продуктов и функций, например

fancyPackage :: BasicDependency -> (BasicDeliverable, HelpfulExtras -> Gravy)

До тех пор выберите вариант, который наиболее точно отражает фактическую сделку. И расскажи нам об этом, чтобы мы могли построить этот консенсус.