Какое место в пакете клики занимают экземпляры QuickCheck?

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

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

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

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

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


haskell cabal quickcheck
person acfoltzer    schedule 12.08.2011    source источник
comment
Возможно, тот факт, что вы видели все использованные эти подходы, указывает на то, что на самом деле нет консенсуса? Или, по крайней мере, не универсальное решение.   -  person C. A. McCann    schedule 12.08.2011
comment
@C. А. Макканн: Конечно, и это был бы правильный ответ. Хотя, кажется, стоит обсудить это.   -  person acfoltzer    schedule 12.08.2011

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

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

person ivanm    schedule 12.08.2011
comment
+1 - в данном конкретном случае образец экземпляра в документации кажется подходящим. В качестве альтернативы, если у вас есть собственный набор тестов, связанный с пакетом (с использованием новых функций тестирования Cabal), тогда документ может просто указывать на экземпляр в источнике самого пакета (который компилируется только для тестирования, а не для установки) - person sclv; 13.08.2011

arrow_upward
3
arrow_downward

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

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

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

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

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

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

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

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

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

person pigworker    schedule 12.08.2011
comment
Спасибо за идеи, в частности за перевод зависимостей; это определенно привлекательная идея для будущего развития клики. А пока я собираюсь попробовать сочетание варианта 4 с вашим предложением эффективной прозы и предложением @ ivanm. - person acfoltzer; 17.08.2011