AK
даже в нашем случае, в идеале вместо стринг был бы Time.Posix
Size: a a a
2019 June 27
AK
но к сожалению, приходиться делать обходы
AK
короче, мой месседж в том, что opaque type/ smart constructors это тема если можно в них заточить бизнес логику(особенно когда её через край много)
AP
Но предположим, что стало можно. Тогда можно было бы сделать так
и останется сделать функцию
а конструктор
type SelectedKey = ... -- этот тип нельзя сконструировать
type RestKey = ... -- а этот - можно
type Cart = Cart { selected : SelectedKey, rest : Dict RestKey v}и останется сделать функцию
select
: RestKey
-> Dict RestKey v
-> (SelectedKey, v, Dict RestKey v)а конструктор
Cart можно будет не прятатьAP
Тут "непрозрачна" только функция изымания из словаря. Она же порождает SelectedKey, который никаким другим способом получить нельзя.
AK
в нашем случае нужно. так как когда меняется "rest" должнен так же поменяться "selected"
AP
select это и сделает
AP
Он возвращает новый словарь и новый selected
AP
Можно ещё сделать непрозрачным RestKey, тогда извлесь из словаря можно будет только через select. Только нужно будет сигнатуру поменять:
select
: Int -- это внешний ключ
-> Dict RestKey v
-> (SelectedKey, v, Dict RestKey v)AK
не могу родить как в данном случае selected связан с Dict
AK
вот мне так понятно
type Cart = Cart { selected : ( SelectedKey, v ) , rest : Dict SelectedKey v}AP
Как сконструировать RestKey (из Int), знает только select. А значит изменить словарь извне не получится — нечем конструировать ключи
AP
И SelectedKey тоже никак не получить, кроме как через selected
AP
Который проследит, что dict поменялся
AP
При такой архитектуре скрывать нужно сильно меньшую часть. Сам Cart полностью прозрачен
AP
И Dict тоже можно использовать обычными способами (кроме модификации)
AP
Если захочется, скажем, распечатать значения словаря (даже с ключами, если для них будет доступна функция
RestKey -> smth), то никаких проблем!AK
осталось дождаться когда в Dict для ключей можно будет свои типы засунуть