Неиспользование статической типизации
Mar. 12th, 2013 03:24 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassСтолкнулся с тем, что наиболее внятно задача, которую я решаю, укладывается в Clojure и не укладывается (без частичного выкидывания статической типизации) в скалы-хаскели-C#-F#.
Вернее даже не выкидывание, а просто получается имитация типичного для Clojure типа данных Map[Symbol,Any] и использование его во все поля.
Можно, конечно, было бы убрать вообще всю логику, вплоть до SQL-запросов, из БД и писать запросы для ORM типа slick, но это в данном случае натягивание совы на глобус, более чем бессмысленное, т.к. статически типизированный результат запроса в ORM нужно будет превратить обратно в нихрена не типизированнный датасет типа Seq[Map[Symbol,Any]] и сериализовать его в json для клиента.
Или прикрутить shapeless (https://github.com/milessabin/shapeless) и навернуть extensible records поверх HList на предмет того, чтобы типовыводилка генерила еще и метаданные, но в итоге получится что-то совсем печальное и малопонятное.
Вернее даже не выкидывание, а просто получается имитация типичного для Clojure типа данных Map[Symbol,Any] и использование его во все поля.
Можно, конечно, было бы убрать вообще всю логику, вплоть до SQL-запросов, из БД и писать запросы для ORM типа slick, но это в данном случае натягивание совы на глобус, более чем бессмысленное, т.к. статически типизированный результат запроса в ORM нужно будет превратить обратно в нихрена не типизированнный датасет типа Seq[Map[Symbol,Any]] и сериализовать его в json для клиента.
Или прикрутить shapeless (https://github.com/milessabin/shapeless) и навернуть extensible records поверх HList на предмет того, чтобы типовыводилка генерила еще и метаданные, но в итоге получится что-то совсем печальное и малопонятное.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-03-12 12:29 pm (UTC)no subject
Date: 2013-03-12 12:36 pm (UTC)Некоторые ну влет укладываются на статическую типизацию, какие-то статические маппинги, ОРМ и прочее.
А вот тупо "взять из базы результат запроса и показать пользователю" тут даже никакое ООП нахрен не нужно, ибо каждого из действующих классов экземпляр строго один, наследование только где-то во внутренностях используемых библиотек, разве что реализация доступа к БД сделана через фабрики коннектов :)
И FP тут только если сильно повезет и результат запроса нужно будет как-то нетривиально обработать.
no subject
Date: 2013-03-12 01:47 pm (UTC)С этой точки зрения мне очень симпатичен подход typescript-а - хочешь смотри на ворнинги, хочешь забей и смотри как оно реально в рантайме падает.
no subject
Date: 2013-03-12 12:59 pm (UTC)no subject
Date: 2013-03-12 12:59 pm (UTC)no subject
Date: 2013-03-12 01:10 pm (UTC)Цель же не статические типы ради них самих, а упрощение себе жизни.
no subject
Date: 2013-03-14 06:00 am (UTC)А макросы не подходят? Они очень сложные и в них запросто быстро запутаться?
no subject
Date: 2013-03-12 01:47 pm (UTC)с одной стороны, тип динамический и снаружи любые данные выглядят как QVariant, в коем виде их можно запихивать в любые контейнеры или контролы
с другой, его можно проверить или извлечь как статический с помощью встроенного или прикрученного метода вроде toInt()
no subject
Date: 2013-03-12 01:53 pm (UTC)no subject
Date: 2013-03-12 01:56 pm (UTC)no subject
Date: 2013-03-12 01:58 pm (UTC)no subject
Date: 2013-03-12 02:07 pm (UTC)И получается что типы почти всегда нужно выводить из результата SQL запроса, и прямо так и отдавать и показывать пользователю, только иногда нужно что-то с ними делать.
no subject
Date: 2013-03-12 05:45 pm (UTC)no subject
Date: 2013-03-12 05:49 pm (UTC)no subject
Date: 2013-03-12 06:40 pm (UTC)Это же абсурд
no subject
Date: 2013-03-12 07:11 pm (UTC)no subject
Date: 2013-03-13 08:27 am (UTC)no subject
Date: 2013-03-14 06:01 am (UTC)no subject
Date: 2013-03-12 08:03 pm (UTC)Ну и задача тоже немного роль играет.