т.е. ничего не теряем

@chebotarevp и уперся в такую проблему: call требует структуру которая невозможна - опциональные поля в ней нужны для конструирования запроса. Т.е. как сериализатор asdf ещё ничего, но как конструктор произвольных JSON - нет.

Вот с последним абзацем я на 146% согласен, сам натолкнулся на кучи проблем когда пытался сделать что-то кастомное, поэтому и пришлось приплести vibe json в проект параллельно.

например как сделать certificate так чтобы он не передавался если нету сертификата?

Ок понял. Кажется что-то там было про optional поля

ну потому что он не конструктор таких объектов :)

Ок понял. Кажется что-то там было про optional поля

Допустим было. Кто даст гарантию что они поддерживают ровно так как оно надо будет телеграму в плане формата результирующего JSON?

сериализация != конструирование сообщения

ну поле в сериализованном json либо есть либо нет. Какой тут еще формат.

ты о чём?

Дубликация

Дубликация

хуекация ну ты понел

ну поле в сериализованном json либо есть либо нет. Какой тут еще формат.

а если надо "иногда есть а иногда нет"? (см. certificate)

Если ты в структуру записал сертификат - значит он есть и поле надо сериализовать. А если ты поле не трогал значит оно пустое и его сериализовать не надо.

сериализации дишных структур такая функциональность не нужна

Если ты в структуру записал сертификат - значит он есть и поле надо сериализовать. А если ты поле не трогал значит оно пустое и его сериализовать не надо.

т.е. начинаем плодить структуры с разными комбинациями опциональных полей?

Не, это все одна структура обслуживает + либо nullable либо @optional

стикеры забанены)

Короче все optional поля из спецификации API не должны сериализоваться если к ним не было обращения либо там лежит default значение

Не, это все одна структура обслуживает + либо nullable либо @optional

Asdf умеет в Nullable?

Короче все optional поля из спецификации API не должны сериализоваться если к ним не было обращения либо там лежит default значение

как определим default значение если оно для max_connections = 40?

щитаю что Asdf не предназначен для конструирования JSON, а значит надо будет его выпилить со временем

Asdf умеет в Nullable?

да

Думаю что надо просто null поля не сериализовать вот и все. В апи вроде нет таких случаев когда явно null посылается

я когда свою либу для бота телеги писал все опциональные поля делал nullable

в обе стороны нормально работает

щитаю что Asdf не предназначен для конструирования JSON, а значит надо будет его выпилить со временем

Asdf это деталь имплементации и тебя не должно волновать как там внутри устроено. Должна быть возможность в любой момент поменять asdf на что то другое и пользователи библиотеки не должны ничего заметить

Такая вот инкапсуляция

Думаю что надо просто null поля не сериализовать вот и все. В апи вроде нет таких случаев когда явно null посылается

а если появятся?

короч, многообразие документов JSON и D не пересекаются полностью

я когда свою либу для бота телеги писал все опциональные поля делал nullable

Просто в vibed nullable как раз дает обратный эффект - такие поля всегда сериализуются со значением null

поэтому всегда есть шанс что что-то будет реализовано костылём

а если появятся?

Надо просто изучить какие возможности предлагают библиотеки, если не будет вариантов ну тогда выкидывать наверно.

Просто в vibed nullable как раз дает обратный эффект - такие поля всегда сериализуются со значением null

ну я то как раз чисто для себя делал, а так понятно что какие то либы вообще могут не уметь работать с Nullable

поэтому всегда есть шанс что что-то будет реализовано костылём

Но я подчеркиваю что это просто не до конца имплементировано, никаких проблем с сериализацией в D я не вижу

Людвиг мог бы добавить атрибутов для конфигурации и тогда каждое поле можно было бы настроить под себя идеально

есть ещё одна засада. т.к. нам нужна не сериализация а конструирование то мы привязываемся к не всегда оптимальной структуре сериализируемого запроса. в телеге могут быть даже устаревшие поля и нам придётся с ними жить, если Update например будет по проекту таскаться

или даже не Update а структура запроса, там вероятнее появление таких полей

было бы неплохо если бы телега как-нить версию api вела или по урлу можно было бы на разные стучаться типа /api/v1, /api/v200

и фиксировала бы изменения

где-то вроде так сделано было, но чет уже не припомню где )

а потом старые апи просто со временем помечаются как устаревшие и закрываются

где-то вроде так сделано было, но чет уже не припомню где )

Hubspot

было бы неплохо если бы телега как-нить версию api вела или по урлу можно было бы на разные стучаться типа /api/v1, /api/v200

Да в ней все сделано вот так квадратно-гнездовым способом, есть уже огромные мануалы с описанием как проектировать апи чтобы учесть все проблемы, но они решили пойти своим велосипедопутем и все шишки набивать с нуля самостоятельно.

начать с того что вообще использован текстовый протокол

ну http это в принципе текстовый протокол, даже если bson передавать по нему )

нет, там же тело можно бинарное слать

ну http это в принципе текстовый протокол, даже если bson передавать по нему )

https://ru.wikipedia.org/wiki/HTTP/2

даже в первой версии можно

файлы аплоадятся бинарно

хедеры все равно текстовые )

https://ru.wikipedia.org/wiki/HTTP/2

знаю, я про http/1.1 :) а так конеш ждем когда все переползут на http/2.0

хедеры все равно текстовые )

это пофик

есть ещё одна засада. т.к. нам нужна не сериализация а конструирование то мы привязываемся к не всегда оптимальной структуре сериализируемого запроса. в телеге могут быть даже устаревшие поля и нам придётся с ними жить, если Update например будет по проекту таскаться

Кстати я же совсем напутал )

Посмотри вот эту ветку https://github.com/nexor/telega/pull/2/files#diff-e40a697166c006a3b50996397422bf86R1050

Я думал что уже смержил замену asdf на vibe json а оказывается нет. В этой ветке я переделал сериализацию в методе callMethod. Как раз из-за тех проблем что ты описываешь.

Из-за того что asdf мне не позволял нормально алгебраики сериализовать

мляя а я уже тоже переделал

кек

@chebotarevp мёрджи тогда это

@chebotarevp ты asdf не убрал. почему?

Да не убрал, потому что десериализовывает то он лучше

аа

я думаю добавить hooks и потом поверх этого навернуть асинхронный класс который можно было бы использовать с любым способом подключения

а ещё заметил что getUpdates при нулевом таймауте почему-то виснет

вроде должен происходить shortpool

Каким образом виснет? Вешает тред? А то с нулевым таймаутом он и должен виснуть бесконечно пока не придет апдейт.

Я с 26го ухожу в отпуск, подмержу все ветки, методов закомичу, исправлю баги и сделаю рефакторинг с учетом пожеланий :)

ERROR: S client not available

Каким образом виснет? Вешает тред? А то с нулевым таймаутом он и должен виснуть бесконечно пока не придет апдейт.

разве? а пишут должен быть short pool

Что это такое?

а хз, они не поясняют. как я понял простая проверка "нету ли там чего"?

и сразу выход

не рекомендуют юзать это сами авторы АПИ

Timeout in seconds for long polling. Defaults to 0, i.e. usual short polling. Should be positive, short polling should be used for testing purposes only.

Хм надо проверить, но я до этого момента был уверен что он бесконечно висит и ждет апдейта, такое поведение и есть.

и нигде не поясняется что такое short pooling

@chebotarevp https://gist.github.com/denizzzka/b02b5c0650980fbfe9ebb819c3094cdf может это будет полезно) правильный способ конвертации json vibe и asdf

и нигде не поясняется что такое short pooling

Какое-то магическое выражение. Когда я подобное описание в STD добавлял, никто такого не говорил.

да, видимо какой-то оборот речи

Вообще это слово гуглится, вроде означает что мы ждем пару секунд и отключаем соединение

значит ни сколько не ждём имеется ввиду

короч, работает оно сейчас явно не так

@chebotarevp https://gist.github.com/denizzzka/b02b5c0650980fbfe9ebb819c3094cdf может это будет полезно) правильный способ конвертации json vibe и asdf

Ок, но вообще для пользователя asdf никак не должна быть видна вообще извне, это чисто приватная инкапсулированная деталь. Для того чтобы из json получить структуру.

Простите, что не в тему, но насколько глубоко обрабатываются рекурсивные шаблоны?

Ок, но вообще для пользователя asdf никак не должна быть видна вообще извне, это чисто приватная инкапсулированная деталь. Для того чтобы из json получить структуру.

да, это для удобства вызова запросов вайба например и парсинга ответов от него

чтобы без кастов странных

хотя хз, касты там встроены

автор asdf неправильно суть кастов понимает, кмк

Нашел сильный аргумент за то чтобы распилить один файл на несколько маленьких - если какие-то функции из модуля не используются и этот модуль не импортируется то он и не будет вкомпилирован, таким образом размер бинарника уменьшится

Нашел сильный аргумент за то чтобы распилить один файл на несколько маленьких - если какие-то функции из модуля не используются и этот модуль не импортируется то он и не будет вкомпилирован, таким образом размер бинарника уменьшится

а разве неиспользуемые функции не вырезаются линковщиком?

чёт это вообще не аргумент

аргумент — читаемость кода

Ну так код как по мне тоже будет более читаемый

а разве неиспользуемые функции не вырезаются линковщиком?

Я щас взял весь модуль telega.botapi, скопировал его в telega.test и сделал import telega.test без всякого использования. Размер бинарника распух на 500кб !

Конечно весь бинарник весит 9мб так что может разница и не так заметна, но полмегабайта мусора это жесть

Причем ldc2 намного эффективнее все это анализирует, там разница реально получилась в 15 байт )

ну так зачем эти псевдомикрооптимизации?

Я щас взял весь модуль telega.botapi, скопировал его в telega.test и сделал import telega.test без всякого использования. Размер бинарника распух на 500кб !

это dmd с флагом -O ?

или debug сборка?

dub -b release