2015-06-23 4 views
3

Мне нужно работать со строгими и ленивыми ByteStrings, потому что это требование задано выбором библиотек (некоторые сочетания happstack, base64, sha256, hexpat и т. Д.). После некоторых танцев с «fromStrict» и аналогичным я закончил с этим:Легкий переход между ленивым и строгим ByteString

import qualified Data.ByteString.Char8 as S 
import qualified Data.ByteString.Lazy.Char8 as L 

class BString s where 
    lazy :: s -> L.ByteString 
    strict :: s -> S.ByteString 
    pack :: String -> s 
    text :: T.Text -> s 

instance BString L.ByteString where 
    lazy = id 
    strict = S.concat . L.toChunks 
    pack = L.pack 
    text = L.fromStrict . TE.encodeUtf8 

instance BString S.ByteString where 
    lazy = L.fromStrict 
    strict = id 
    pack = S.pack 
    text = TE.encodeUtf8 

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

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

Спасибо.

ответ

1

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

Как только вы выбрали свои модули, подписи функций библиотеки никогда не будут меняться. То есть, вы знаете, какая строка вызовет вызов base64 encode, вернется (по вашему выбору модуля.) Поэтому, если вам нужно объединить две библиотечные функции, вы точно знаете, какие преобразования нужно сделать, чтобы они соответствовали друг другу.

+0

Ну, теоретически это может сработать, но мое намерение - это обратное: уменьшить количество кода, который я должен написать. И в некотором смысле «ленивый strictString» уже является достаточно хорошим адаптационным слоем. –

+1

Посмотрите на пакет [stringable] (https://hackage.haskell.org/package/stringable). – ErikR