А если ты уверен в типе, то проверок не надо

Ну зависит от проекта.

У меня буквально 2-3 структуры бывает.

Так проще.

?

А если ты уверен в типе, то проверок не надо

Я не уверен вот в случае сверху. У меня там каждый раз может быть абсолютно что угодно.

if update["@type"].(string) == "updateNewMessage" { if message, ok := update["message"]; ok { if chatId, ok := message.(tdjson.Update)["chat_id"].(float64); ok { if isOutgoing, ok := message.(tdjson.Update)["is_outgoing"].(bool); ok { if content, ok := message.(tdjson.Update)["content"]; ok { if text, ok := content.(tdjson.Update)["text"].(string); ok { if allowedBots[chatId] { if !isOutgoing {

а вы уверены в своём апи и что там всегда будет @type?

а вы уверены в своём апи и что там всегда будет @type?

Да, тип оно всегда передает.

К счастью

? но это не точно)))

блеать, у меня мозги забекрень уже ?

? но это не точно)))

Я отсекаю все обновления без типа в основном цикле, просто скипаю их.

Так что всё ок.

Проблема: есть набор моделек и они ни заполняются из функции поиска, у каждой модельки есть фабрика которая получает запись бд и заполяет структуру. Каждая модель в своем пакете.

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

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

я хотел обойти следующим образом: сделать внутри структуры модели метод fill и в поиск скормить структуру (под видом интерфейса)

Ну смотри. Например юзаешь ты какой-то очень хитровыебанный API. И тип там приходит не как название поля, а специальным системным полем "@type". Например тебе может придти сначала это: { "data": { "object": "bank_account", "id": "ba_123", "routing_number": "110000000" } } А потом это: { "data": { "object": "card", "id": "card_123", "last4": "4242" } }

Очень странно.. Никогда такого не видел.

а потом в слепую у интерфейса сделать fill

Посмотри протокол MTProto. У него весь API выполнен в таком стиле.

Это ответ @chebyrash

но задумка не удалась, ибо fill должен тип возращаемого значения тоже должен быть интерфейсом (что бы мы в поиске не упоминали его пакет)

а если я уже в реализации попытаюсь вернуть new(Struct) на ссылочный тип интерфейса получу кукишь

func (p DataModel) Fill(entity *anyType) *Interface { return &DataModel{} }

если вернуть func (p DataModel) Fill(entity *anyType) *DataModel { return &DataModel{} } то он уже при накормки поиска будет орать что типо "общали там интерфейс"

Ну да, нужно было нагенерить 18 тысяч строк кода.

вот прям 18 тысяч? или это, гм, преувеличение?

вот прям 18 тысяч? или это, гм, преувеличение?

Нет.

Скорее всего даже больше.

То есть тебе в данном случае надо сначала распарсить тип и в зависимости от этого сделать анмаршалинг по необходимой структуре.

в чем проблема?

Я бросил идею, когда понял, что там скорее всего придется ещё больше кода генерировать.

Скорее всего даже больше.

а что за задача такая, что вот прям 18 тысяч?

а что за задача такая, что вот прям 18 тысяч?

Высокоуровневая обертка для MTProto.

там нет кода на 18К строк

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

там нет кода на 18К строк

Да я ё-маё, ну вот глянь пример. Это не мой код, но там даже не самая последняя схема. 63 вроде, а сейчас почти 80-ая. https://github.com/shelomentsevd/mtproto/blob/master/api.go

Если на 80-ые лейеры сделать, будет все 25к

в гоу полная боль блин ?

не возможно структуировать в обертку ничего

как только начинаешь плодить обертки-ар все капец

а без них код хендлеров это полный трешь на 300 строк

причем копипастом в 7 местах (по числу хендлеров)

хотел сделать худые хендлеры, основной код вынести в библиотеки, сделать модели

причем копипастом в 7 местах (по числу хендлеров)

так выносите копипасту в отдельную функцию и юзайте ее

Да я ё-маё, ну вот глянь пример. Это не мой код, но там даже не самая последняя схема. 63 вроде, а сейчас почти 80-ая. https://github.com/shelomentsevd/mtproto/blob/master/api.go

посмотрел. кода там много, но впечатления генеренного он не производит.

посмотрел. кода там много, но впечатления генеренного он не производит.

Это кодеген

100%

Тулза от того же автора лежит на гитхабе

Но она на питоне

так выносите копипасту в отдельную функцию и юзайте ее

не выйдет, код то разный. Просто открыть бд, прочитать, закрыть записать

это уже 50 строк

вот это все говно и ездит

посмотрел. кода там много, но впечатления генеренного он не производит.

https://github.com/shelomentsevd/tl2go

не выйдет, код то разный. Просто открыть бд, прочитать, закрыть записать

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

это понятно, никто в один файл 22К строк не сложит из людей. но я не про собственно гошные строки, а про логику. она там не шаблонная

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

а там начинаются циклические зависимости

поиск -> нашел модель -> модель дернула поиска -> не скомпилилось

это понятно, никто в один файл 22К строк не сложит из людей. но я не про собственно гошные строки, а про логику. она там не шаблонная

Потому что Golang для реализации MTProto слабо подходит. Там TL-схемы полагаются на классы. Это... гхм... Вызывает некоторые сложности.

ага, циклические то запрещены

начинаешь плодить огород из интерфейсов

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

ага, циклические то запрещены

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

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

я выше в 7 сообщениях изложил

начинаешь плодить огород из интерфейсов

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

только вы пропустили

ERROR: S client not available

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

+

я сознательно пробустил

Проблема: есть набор моделек и они ни заполняются из функции поиска, у каждой модельки есть фабрика которая получает запись бд и заполяет структуру. Каждая модель в своем пакете.

вот первое

и что?

и ничего, решение уже нет неделю сижу с этим

да почему нет-то?

ну а как?

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

Ну вот пример из TL-схемы TDLib (там упрощеннеые используются): //@class AuthorizationState @description Represents the current authorization state of the client //@description TDLib needs TdlibParameters for initialization authorizationStateWaitTdlibParameters = AuthorizationState; //@description TDLib needs an encryption key to decrypt the local database @is_encrypted True, if the database is currently encrypted authorizationStateWaitEncryptionKey is_encrypted:Bool = AuthorizationState; //@description TDLib needs the user's phone number to authorize authorizationStateWaitPhoneNumber = AuthorizationState; Другими словами в ответе приходит не тип AuthorizationState, а его "подтип" из класса типов. И так выглядит весь MTProto. Нужно древовидно парсить ответ, спускаясь всё ниже, определяя вложенные типы. Ответ всегда может быть разным. У него нет какой-то определенной структуры. Поэтом без type assertion практически невозможно сделать.

описали ваши модельки в yml, написали генератор кода - и понеслась. да, у этого подхода есть сложности. но - это путь и он рабочий.

main -> handler -> search -> user -> core -> search -> core

один из вариантов тупика

у меня родился план, как не инклюдить в поиске user, но он тоже провалился достаточно

(через интерфейсы - кормим в поиск структуру пользователя, далее делаем вид в поиске что работае с интерфейсом)

описали ваши модельки в yml, написали генератор кода - и понеслась. да, у этого подхода есть сложности. но - это путь и он рабочий.

А раньше все кричали про ооп, паттерны переиспользования кода, а теперь кодо генератор и копипаста, мода однако)))))

еще и база не реалиционная

Ну вот пример из TL-схемы TDLib (там упрощеннеые используются): //@class AuthorizationState @description Represents the current authorization state of the client //@description TDLib needs TdlibParameters for initialization authorizationStateWaitTdlibParameters = AuthorizationState; //@description TDLib needs an encryption key to decrypt the local database @is_encrypted True, if the database is currently encrypted authorizationStateWaitEncryptionKey is_encrypted:Bool = AuthorizationState; //@description TDLib needs the user's phone number to authorize authorizationStateWaitPhoneNumber = AuthorizationState; Другими словами в ответе приходит не тип AuthorizationState, а его "подтип" из класса типов. И так выглядит весь MTProto. Нужно древовидно парсить ответ, спускаясь всё ниже, определяя вложенные типы. Ответ всегда может быть разным. У него нет какой-то определенной структуры. Поэтом без type assertion практически невозможно сделать.

при чем тут type assertion? к вам приехал пакет, вы его распарсили. тип его при этом выяснился однозначно. зачем assertion?

А раньше все кричали про ооп, паттерны переиспользования кода, а теперь кодо генератор и копипаста, мода однако)))))

По идее кодеген это решение в пользу скорости.

А раньше все кричали про ооп, паттерны переиспользования кода, а теперь кодо генератор и копипаста, мода однако)))))

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

при чем тут type assertion? к вам приехал пакет, вы его распарсили. тип его при этом выяснился однозначно. зачем assertion?

Потому что я не знаю как описать объект детерминированной структурой. Условный тип FileInput может появиться как в глубине объекта, так и прям в самом корне. Может, я конечно, чего-то не понимаю...

По идее кодеген это решение в пользу скорости.

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

Потому что я не знаю как описать объект детерминированной структурой. Условный тип FileInput может появиться как в глубине объекта, так и прям в самом корне. Может, я конечно, чего-то не понимаю...

Разве что сделать какую-то генерик структуру в которой лежат абсолютно все типы.

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

Короче были бы генерики, было бы легче))0

Короче были бы генерики, было бы легче))0

вот не уверен. с чего бы?

Я прекрасно осознаю, что в 90% случаев можно обойтись без них.

Но конкретно в моем кейсе они бы не помешали.

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

Почему? Если нормально написано, то в большинстве случаев вполне читаемо и разбираемо и комментарии с интерфейсами никто не отменял

вот не уверен. с чего бы?

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

Я прекрасно осознаю, что в 90% случаев можно обойтись без них.

+ но с ними становится в этих 90% намного легче))))

+ но с ними становится в этих 90% намного легче))))

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

Потому что я не знаю как описать объект детерминированной структурой. Условный тип FileInput может появиться как в глубине объекта, так и прям в самом корне. Может, я конечно, чего-то не понимаю...

есть у меня нехорошее подозрение, что все эти FileInput надо разными типами делать. вот прям все варианты