![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Необъяснимые вещи необъяснимы
В firebird-devel обсуждают новый ABI/API для Firebird.
Вот этот товарищ: http://en.wikipedia.org/wiki/Jim_Starkey навязывает всем свое видение, на тему использования чего-то JDBC-подобного на C++ в качестве базового клиентского API. Остальные кто в лес, кто по дрова - предлагают генерировать API из IDL, использовать plain C апи, кое-кто вспоминает что на улице 2014 год и вообще не помешало бы JSON-апи уже сделать, ссылаются на оракловский OCI и TDS от mssql и прочую чернягу.
Еще один камень преткновения - использование виртуальных функций для чтения значений полей vs чтение напрямую значений из буфера, который прислал сервер при фетче.
По-моему, они все упоролись. Генерировать API хорошая идея, но не из оккультного IDL же.
Впрочем, тут изначально все плохо, т.к. БД по самой своей сути - это динамическая типизация, с вычитыванием схем и результатов парсинга запросов и в конечном итоге оно всегда сводится к мерзости вида "скрестим динамическую типизацию с языками со статической недотипизацией вроде С".
Вот этот товарищ: http://en.wikipedia.org/wiki/Jim_Starkey навязывает всем свое видение, на тему использования чего-то JDBC-подобного на C++ в качестве базового клиентского API. Остальные кто в лес, кто по дрова - предлагают генерировать API из IDL, использовать plain C апи, кое-кто вспоминает что на улице 2014 год и вообще не помешало бы JSON-апи уже сделать, ссылаются на оракловский OCI и TDS от mssql и прочую чернягу.
Еще один камень преткновения - использование виртуальных функций для чтения значений полей vs чтение напрямую значений из буфера, который прислал сервер при фетче.
По-моему, они все упоролись. Генерировать API хорошая идея, но не из оккультного IDL же.
Впрочем, тут изначально все плохо, т.к. БД по самой своей сути - это динамическая типизация, с вычитыванием схем и результатов парсинга запросов и в конечном итоге оно всегда сводится к мерзости вида "скрестим динамическую типизацию с языками со статической недотипизацией вроде С".
no subject
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Проблемы с типизацией - да, есть, портят все высокие материи и хорошие начинания, но не agda ж там ожидать. А коли так - детали реализации становятся не столь принципиальны.
Как по мне - так нехай делают JSON, "решение проблем с типизацией положением на оную болта".
Для компилируемых языков - ребе, а шо ви таки видите плохого в IDL? Механизм описания как механизм, даже "типа стандартизированный". Альтернатива - генерировать из невменяемого XML с десятком ns, ссылками на черновики стандартов OASIS, жабоёбством и ебаквачеством. И документировать там же докбуком.
no subject