Эквивалент .NET InternalsVisibleTo в Haskell

В .NET я могу украсить свою сборку следующим атрибутом:

[<assembly: InternalsVisibleTo("MyProject.Test")>]

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

Мне интересно, есть ли что-то подобное в мире Haskell. Допустим, у меня есть библиотека со следующим файлом .cabal:

library
  exposed-modules:  MyLibrary.API
  other-modules:    MyLibrary.Utils
  -- ...

test-suite mylib-test
  -- ...
  build-depends:  base,
                  hspec,
                  my-library

Есть ли способ обратиться к MyLibrary.Utils из mylib-test test-suite?


unit-testing haskell internalsvisibleto
person Alojzy Leszcz    schedule 31.01.2021    source источник

Ответы (1)


arrow_upward
5
arrow_downward

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

library utils
    exposed-modules: MyLibrary.Utils

library
    exposed-modules: MyLibrary.API
    build-depends: utils

test-suite mylib-test
    build-depends: base, hspec, my-library, utils

С другой стороны, существует строгая конвенция о том, что модуль в любом случае раскрывается, но включает Internal в его имя и сообщает людям в документации, что вы сломали его, что вы его купили.

person Daniel Wagner    schedule 31.01.2021
comment
Звучит нормально. Я попробую. Спасибо. - person Alojzy Leszcz; 01.02.2021
comment
Я новичок в мире Haskell, поэтому не знаю соглашений. Если вы говорите, что он сильный, то, думаю, лучше ему следовать, не так ли? :) - person Alojzy Leszcz; 01.02.2021
comment
@AlojzyLeszcz Будьте тем изменением, которое вы хотите увидеть в мире. Вот почему я использую исключительно метрику, несмотря на то, что живу в США. (Тем не менее, мне не ясно, что внутренние библиотеки являются явно лучшим выбором. Есть кое-что интересное в том, чтобы дать возможность возиться с внутренними компонентами, когда того требует ситуация, а также есть кое-что интересное в том, чтобы никогда не иметь дело с жалобами от людей, которые зависели от внутреннего устройства и расстраивались, когда они менялись.) - person Daniel Wagner; 01.02.2021
comment
Я думаю, было бы хорошо отметить, что внутренние библиотеки еще не имеют полной поддержки - я считаю, stack с ними нельзя использовать. Так что лично я не буду использовать внутренние библиотеки, пока stack не получит для них поддержку. - person bradrn; 01.02.2021
comment
@DanielWagner Я попробовал и создал еще одну библиотеку в моем файле .cabal. Он работает хорошо, единственная проблема, с которой я сейчас сталкиваюсь, заключается в том, что cabal new-haddock также пытается создать документацию для utils библиотеки. Есть ли способ указать ему создавать документ только для основной библиотеки? - person Alojzy Leszcz; 01.02.2021
comment
@AlojzyLeszcz А, хм. Я не уверен, есть ли кабальный путь, но у пикши есть инструменты, чтобы сообщить, для каких модулей создавать документы, и даже способ указать, какой модуль должен быть основным модулем для экспортируемого символа (т.е. если несколько модулей экспортируют символ , ссылка на которую должна быть упомянута другими). Подробные инструкции есть в руководстве пользователя пикши. - person Daniel Wagner; 01.02.2021
comment
Спасибо. Я посмотрю на документы клики и пикши. - person Alojzy Leszcz; 01.02.2021