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

Вопрос был именно к этому коду

перепишу Ваше решение, в точности так, как я предложил выше.

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

Ты хочешь чтобы я сначала у себя реализовал эту логику?

Согласно здравому смыслу бремя доказательства (см. ссылку выше на Чайник Рассела) лежит на утверждающем. Ваша милость утверждает, что подход описываемый мною, не заработает. Я уверен в обратном, имею работающие, живые доказательства. Я определенно не должен ничего писать, чтобы проиллюстрировать заблуждение, которое у меня, я уверен, отсутствует, а Вы утверждаете что есть.

Окей, я напишу, мне не сложно. Я просто написал тебе задачу на расширение, хотел чтобы ты сначала сам попробовал, но если тебе проще по моему коду, я ща напишу

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

там в ответе сслыка на рабочий код tdlib!

Дело не в том как можно или нельзя написать, а в самом таймлайне разработки - была одна задача - появился код со свитч кейсами, задача расширилась - теперь либо ещё один свитч кейс написать (тот же самый по сути), либо сломать и переделывать существующий код

этот switch в одном-единственном месте, в котором код и правда ветвится, и разработчик новый поймет все сразу

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

в моем понимании < 10

Если считаете это нормальным, могу только позавидовать Вашему трудолюбию, оно нужно :)

Если считаете это нормальным, могу только позавидовать Вашему трудолюбию, оно нужно :)

но если что эти 10 кейсов можно написать же 1 минуту, не так ли?) прямо на будущее?)

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

это не трудолюбие, это - лень и забота о тех, кому это потом читать

Пример слишком простой, в реальности кейса в свитче не три, и функций не две

Весь вопрос а аудитории читающих :)

Спокойной

могу конечно, такой код вообще нельзя выдавать наружу, а ошибку, что "пользователь забанен" - или что там с ним случилось, должен возвращать Send, чтобы не грузить прикладного программиста двумя вызовами, вместо одного кроме того, проверка такого сорта - не факт, что может быть применена вообще к какому-то messenger, например, в случае со slack - проще стукнуться и узнать, что hook больше не работает, чем сначала делать к нему HEAD, прежде чем отвалиться

могу конечно, такой код вообще нельзя выдавать наружу, а ошибку, что "пользователь забанен" - или что там с ним случилось, должен возвращать Send, чтобы не грузить прикладного программиста двумя вызовами, вместо одного кроме того, проверка такого сорта - не факт, что может быть применена вообще к какому-то messenger, например, в случае со slack - проще стукнуться и узнать, что hook больше не работает, чем сначала делать к нему HEAD, прежде чем отвалиться

А если потребуется проверкой защитить какой-то другой метод. Ну не только же Send бывает, и не все провайдеры такие крутые как телеграм и поддержкивают универсальные сообщения на все случаи жизни? Скажем нужно нам забирать через какое-то время информацию о том прочитал пользователь сообщение или нет. Что-то типо provider.IsUserReadMessage(...) перед тем как мы проверим эту информацию, нам необходимо еще раз чекнуть не забанен или пользователь с тех пор как мы ему отправили сообщение.

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

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

strings.Trim()

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

https://play.golang.org/p/-oCHrE9L9jn Вот. 1. Удалил CanSend который проверял наличие Networktype у пользователя, у себя тоже можешь убрать, он все равно к вопросу об интерфейсах отношения не имеет 2. Добавил метод IsMessageRead который проверяет было ли прочитано сообщение пользователем (Теперь Send возвращает Id сообщения). 3. Добавил метод IsUserBanned его надо вызвать перед отправкой сообщения (Send) и перед проверкой на прочитанность сообщения (IsMessageRead). Ты там в коде увидишь. Ну и все, задача твоя как и в прошлый раз избавиться от интерфейса SendProvider

я подошел к ответу, как и обещал довольно серьезно, прошу отнестись так же, и не писать - "нет ты вот сделай, чтобы мой модельный пример, по формальным признакам работал" - мы это сделали вчера ночью, и вроде все получилось.

Всем привет а чайникам сюда можно? Или может есть канал для начинающих?

Не осилил голанг, перешел на питон)

Golang - проще в итоге значительно

Golang - проще в итоге значительно

Вот такой вопрос: если каждая функция возвращает error , то под каждым вызовом делать проверку егога этого на nil, получается надо. А нет какого-то return_if? Это же адик какой-то везде ифы эти .

Вот такой вопрос: если каждая функция возвращает error , то под каждым вызовом делать проверку егога этого на nil, получается надо. А нет какого-то return_if? Это же адик какой-то везде ифы эти .

вы недостаточно понимаете логику го и его развития и возможно стоит почитать любой тикет в github голэнга, например про тернарную операцию. Если же открытие гитхаба или, ни дай боже, стэковерфлоу с гуглом представляет такую трудность, то стоит просто подумать - «а что если весь код будет предельно простым, однозначно понимаемым и читаемым, на сколько проще станет людям после меня разбираться с ним через 5-10 лет?». Или же «а что если все безумные идеи по улучшению синтаксиса появятся в языке, как его смогут понимать?»

Там есть своя библиотека, для тестирования и Error'ов.