Oℕ
если у вас потом нужно потреблять эту функцию, вам снова нужно матчить
Size: a a a
2020 August 04
Oℕ
это не более простой код, потому что вы просто вытащили часть кода в доп функции
Oℕ
результирующее решение более сложное
Oℕ
хотя кажется, что оно более простое, потому что код на мониторе требует понимания меньшего количества базовых концептов языка
Oℕ
в результате вы делаете больше матчингов и проверок, которые могли бы не делать
это приводит либо к возрастанию количества тестов, и рантайм ошибок, которые гипотетически не должны возникать,
либо к коду, который делает имплиситные догадке а-ля Option.get
суть в том, что так же, как и в случае Option.get исключить невозможные сценарии с помощью типов
это приводит либо к возрастанию количества тестов, и рантайм ошибок, которые гипотетически не должны возникать,
либо к коду, который делает имплиситные догадке а-ля Option.get
суть в том, что так же, как и в случае Option.get исключить невозможные сценарии с помощью типов
SA
Так матчить все равно придется? Даже если написать
processAuthReq[A](req: AuthRequest[A]): Result[A], где Result - GADT. Знания A почти наверняка не хватит, чтобы интерпретировать ResultOℕ
Конечно, можно еще тайпклассов навертеть над
A. Но выглядит сложным, мне не приходит в голову задач, где такое абстрагирование окупилось бы. Возможно, нужно больше практики.ну например
здесь вы получаете возможность определить Encoder[Token] без того, чтобы перегонять данные в JSON, даже если они не будут енкодится
sealed trait Token
case class SimpleToken(str: String) extends Token
case class JsonToken[A: Encoder](a: A) extends Token
здесь вы получаете возможность определить Encoder[Token] без того, чтобы перегонять данные в JSON, даже если они не будут енкодится
Oℕ
соответственно, это называется экзистенциальными типами
Oℕ
а предыдущая форма называется индексированными типами
𝛈µ
а что такое ГАДТ?
𝛈µ
прекрасная статья, всё разжёвано
𝛈µ
Теперь доволен?
Oℕ
SA
sealed trait AuthRequest[A]
case class SimpleAuth(user: String, password: String) extends AuthRequest[(String, String)]
case class BearerAuth(token: String) extends AuthRequest[String]
case class ExternalAuth(provider: String, id: UUID) extends AuthRequest[ExtAuth]
def getAuthReqData[A](req: AuthRequest[A]): IO[A] = req match {
case SimpleAuth(user, password) => (user, password).pure[IO]
case BearerAuth(token) => token.pure[IO]
case ExternalAuth(provider, id) => getExtAuthFor(provider).getAuthData(id)
}
Понял, чем мне не нравится этот пример. мы в GADT закодировали часть внешней логики. Тип ExtAuth не относится к AuthRequest, это часть модели реализации внешней аутентификации.
Похоже на DDD, когда бизнес-логика вносится непосредственно в модель.
Похоже на DDD, когда бизнес-логика вносится непосредственно в модель.
Oℕ
Понял, чем мне не нравится этот пример. мы в GADT закодировали часть внешней логики. Тип ExtAuth не относится к AuthRequest, это часть модели реализации внешней аутентификации.
Похоже на DDD, когда бизнес-логика вносится непосредственно в модель.
Похоже на DDD, когда бизнес-логика вносится непосредственно в модель.
относится
Oℕ
но думаю, что эти рассуждения об отствутвующем коде уже не относятся к мотивации ГАДТ
Oℕ
стоит упомянуть, что экзистенциальную форму можно заенкодить и другими способами, например
trait JsonToken extends Token{
type A
implicit def encoder: Encoder[A]
val a : A
}
но использовать её гораздо сложнееOℕ
а вот индексы почти никак иначе не заенкодить в скале, единственный альтернативный способ, который я знаю - это ТФ
Oℕ
неполноценный способ мог бы выглядеть так
sealed trait AuthRequest[A]
case class SimpleAuth[A](user: String, password: String, ev: A Is (String, String)) extends AuthRequest[A]
case class BearerAuth[A](token: String, ev: A Is String) extends AuthRequest[A]
case class ExternalAuth[A](provider: String, id: UUID, ev: A Is ExtAuth) extends AuthRequest[A]Oℕ
всё потому что в скале нет эквивалента хаскельного
~ - ограничения, из которого компилятор мог бы получить равенство типов для унификации