надо читать апдейты с сервера, брать update_id и указывать его при следующем запросе (или update_id+1)

но если GetUpdates возвращает канал из которого я в бесконечном цикле вычитываю, то каким образом мне указать ему update_id?

замена pook тут будет иметь такой же эффект тут, как замена fack в (плохом) языке с перегрузкой (читай С++).

Код скинь, фантазировать сложно.

updates, err := bot.GetUpdatesChan(u) for update := range updates { if update.Message == nil { continue } processUpdate(bot, update, record, db) } то есть что-то типа такого

pook.BlaBla(fack) — этот код в голанге может сделать что угодно, чем это лучше чем pook >> fack совершенно неясно

"gopkg.in/telegram-bot-api.v4"

заменить вообще можно ВСЁ! 🙂 дело в том что если тебе нужно поменять, то менять лучше только в 1 месте, меньше вероятности ошибиться. Если у тебя 4 перегруженных функции, тогда меняет придётся в 4 местах и забыть одну из них или ошибиться в её реализации очень просто и Ken Thompson если я не ошибаюсь был против перегрузки, ты можешь поспорить с моей аргументацией, но с Ken'ом спорить не рекомендую, не смотря на то что его аргументация будет аналогичной))

Я сейчас стикеры так же начну тебе отправлять, лол. Ты вообще понимаешь, что вызов через точку — это та же перегрузка по левому аргументу точки?

перегрузка чего?

"gopkg.in/telegram-bot-api.v4"

https://github.com/go-telegram-bot-api/telegram-bot-api/commit/5f38203a155afa901c7deb70596a088a8424a9ee вот тут перестали +1 делать)

это лучше тем, что понятно, где глядеть реализацию

тяжело наверное жить без грепа

все они знают что делают... до поры до времени, а потом забывают, что они там делали, либо просто уходят и на их место становятся люди, которые ничерта о коде не знают))) меняют только одну из функций забыв изменить другие перегруженные и всё вообщенакрывается медным тазом))) перегрузка это многозначность! это прямое нарушение DRY принципа приводящая к порой страшным последствиям

блин, это все обьясняет :D

перегрузка чего?

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

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

перегрузка конструкции .BlaBla(...)

тяжело наверное жить без грепа

как не объясняет, если объясняет?

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

Конструкция .BlaBla(...) является неоднозначной и "перегруженной" в случае, если сущность перед точкой является интрефейсом.

У него там не много не правильно. Щас скопипстю с рабочего пример.

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

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

Вы опять говорите про C++, C++ говно и с ним работать не стоит, мы это уже выяснили. Но есть же языки с нормальной реализацией адхок полиморфизма

перегрузка операторв - везде говно

а что с ней не так?)

нет, она всегда является перегруженной по типу того, что слева от этой конструкции

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

ну если остановить приложение и запустить заново то он опять переберет все апдейты с 0. Там по-моему за последний час апдейты будут

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

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

> Но в случае структур на этапе компиляции можно с уверенностью сказать, что будет делать BlaBla, а в случае интерфейсов такого уже сказать нельзя А это уже статическая/динамическая диспетчеризация, а не перегрузка.

нет

Сколько структур может реализовывать один и тот же интерфейс?

Тут о том, что во время вызова у тебя есть одна конкретная

Сколько структур может реализовывать один и тот же интерфейс?

@Gromnsk https://play.golang.com/p/EypBu4Q3TNp

@Gromnsk https://play.golang.com/p/EypBu4Q3TNp

некоторое количество. и не всегда я знаю, какая именно структура сейчас на месте интерфейса. но этих структур в проекте - ограниченное количество

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

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

Задротство на полинге делать ботов. Нужно юзать вебхуки, а в помощь ngrok, кстати у Василия на Курсере есть прекрасное видео.

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

миллион структур вы не напишете даже с помощью кодогенерации. не надо ля-ля

классическая схема такая: user.Activize() repo.Save(user) но repo.Activize(userId) тоже имеет право

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

зависит от реализации

Двадцать напишу, а даже двадцать - это уже очень много.

двадцать структур, реализующих один интерфейс, и методы которых делают существенно разное? не надо ля-ля

Плохо ли будет если будет обновлять все поля?)

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

перегрузка операторв - везде говно

Как раз наоборот. DRY - это don't repeat yourself. Ни о какой однозначности тут речи не идёт вообще. Но на практике DRY как раз реализуется черз то, что одна и та же вещь имеет несколько значений, чтобы избежать всякой копипасты.

Как раз наоборот. DRY - это don't repeat yourself. Ни о какой однозначности тут речи не идёт вообще. Но на практике DRY как раз реализуется черз то, что одна и та же вещь имеет несколько значений, чтобы избежать всякой копипасты.

Вы опять говорите про C++, C++ говно и с ним работать не стоит, мы это уже выяснили. Но есть же языки с нормальной реализацией адхок полиморфизма

ты когда логику перегруженной функции меняешь, тебе её во всех её вариациях нужно обновить. это не DRY

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

Каких ещё вариациях? Перегруженные функции - это разные функции.

так в этом то и проблема))) (потенциально) разное поведение скрытое под одним словом

Каких ещё вариациях? Перегруженные функции - это разные функции.

так в этом то и проблема))) (потенциально) разное поведение скрытое под одним словом

Стыдно же гуглить не уметь. "Кросскомпиляция golang"

.BlaBla() скрывает потенциально разное проведение под одним словом, и что с этим делать?

.BlaBla() скрывает потенциально разное проведение под одним словом, и что с этим делать?

о боже... да как же вы "абстракцию" (которую мы НАМЕРЕНО встраиваем) с многозначностью встроенной по ошибке не отличаете то...