> А оно работает также как "классика" мммм... вообще под капотом оно в принципе не так работает....

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

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

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

а ещё мы будем эмулировать ООП. потому что мы так привыкли

не к Go, но на стандартной питоновской библиотеке letsencrypt на питоне очень видно ООП головного мозга. его туда похоже из принципа кувалдой вбивали

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

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

а ещё мы будем эмулировать ООП. потому что мы так привыкли

зачем его эмулировтаь? оно работает так из коробки

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

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

зачем его эмулировтаь? оно работает так из коробки

нет

давай пройдёмся по кругу

да хоть по квадрату. по ссылке выше все написано. контраргумент "нет". Не получается диалога

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

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

что такое ООП?

расскажи, пожалуйста

https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

Скажите мне лучше, есть какая-нибудь релевантная коммуна по разработке ботов телеграм. Что-то у меня разочарование в протоколе. Бэкинжинирить приходится

https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

нет

иерархии классов в Пщ нет

что - нет

что такое ООП?

конечно же я имел ввиду парадигму C++/Java в контексте беседы. конечно же создатели Go xtndthnm dtrf считают, что изобрели ООП-ng. и так это и называют. хвастаясь ng и противопоставляя это C++/Java

никто ничего не противопостовляет

они создают интсрумент

не особо сложный

что - нет

это определение, а не контекст беседы, который изначально был из моего "не тащите сюда свои паттерны из C++" (так любимого тобой, я помню)

который хорошо забивает гвозди

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

можно пояснить чем отличается класс от стракта с методами? ну то есть чем отличается класс, в котором инстанциировав его объект, мы можем обращаться к его методам, от стракта, в котором инстанциировав его объект, мы можем обращаться к его методам?

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

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

нет наследования

а вот вопрос - а что у кого на go написано? а то мало ли, по клавиатуре стучать - дело не хитрое

у нас несколько прокси к базе и другим сущностям.

еще я как-то rtb dsp на нем наваял

а вот вопрос - а что у кого на go написано? а то мало ли, по клавиатуре стучать - дело не хитрое

у меня пока только Hello world https://github.com/diphost/nagtlg/ мне там ничего уже не нравится (не функционал, а как сделал), но оно уже почти полгода в бою

а вот вопрос - а что у кого на go написано? а то мало ли, по клавиатуре стучать - дело не хитрое

хотел ещё сделать утилиту на основе вот этого https://github.com/ericchiang/letsencrypt но легче оказалось в итоге сделать https://github.com/schors/perkele

~45 микросервисов в сфере бух учета, составляющие единую систему, на каждый сервис 2000-7000 строк, и что интересно ни разу не понадобилось наследование, полифоризм и прочее, после крестов, ruby было жутко непривычно, но со временем находятся другие способы решения проблем, более ситуабельные, более go way, как правильно сказал фил насчет проецирования подходов из других языков, в мире го свои способы решения задач, любое сравнение вводит в путаницу и замедляет процесс обучения

~45 микросервисов в сфере бух учета, составляющие единую систему, на каждый сервис 2000-7000 строк, и что интересно ни разу не понадобилось наследование, полифоризм и прочее, после крестов, ruby было жутко непривычно, но со временем находятся другие способы решения проблем, более ситуабельные, более go way, как правильно сказал фил насчет проецирования подходов из других языков, в мире го свои способы решения задач, любое сравнение вводит в путаницу и замедляет процесс обучения

не про Go - реально бухучет на микросервисах? я тут себе переделать пытаюсь - у меня никак всё это расцепить не удаётся. везде нужна одна большая транзакция и консистентность

да, кстати. как сделать атомарные операции на нескольких микросервисах? типа two phase commit. Кто как решает?

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

принято

а чем такой самопил лучше, чем всякие ораклы и прочие постгресы?

а чем такой самопил лучше, чем всякие ораклы и прочие постгресы?

микросервисы не общаются с базами - они общаются с другими микросервисами

Связывать сервисы через базу дынных бэдвей

Данных

Логика перетекает в sql запросы и размазывается по микросервисам

Вместо одной входной точки получаем две

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

нет в go oop, вы чего, и слава желтой кукурузе, что нет

лучше расскажите, какому типу написания возвращаемых значений отдаете предпочтение: прямо указываете или используете именованные параметры в объявлении?

это почему же в go нет ооп?

что за бред

прочитайте значение ооп

как то пустой ретурн смущает

ооо

ну ок

прочитайте значение ооп

и какое же оно в вашей интерпритации?

википедии достаточно 1й абзац

методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса[1], а классы образуют иерархию наследования

классов нет, наследования нет

просто они не такие как с++ и все, но это не значит что это не ооп

можно по разному подходить к этому вопросу

можно вкладывать структуру в структуру

писать код так как пакет = класс

можно по разному подходить к этому вопросу

это уже философия

это не философия

это матчасть

нам так преподавали

и вообще

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

ERROR: S client not available

это я к тому

С++ пардон

уже сплю

не удачная реализация

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

1) в интерфейсах лучше именованные 2) если идет два подряд значения одного типа - именованные (в интерфейсах) 3) если между декларацией и ретурном больше одного экрана, то а) емкие имена переменных б) никаких именованных ( постоянно придется смотреть что же именно возвращает функция) 4) при комплексной логике и вложенных блоках, именованные могут дать сайд эффект

и все же, про возвращаемые значения, какие используете?

Сейчас пример оформлю

Сейчас пример оформлю

супер

ну ок, давай так

минуту

https://play.golang.org/p/br_IaYdPe3

решение - обьявить err заранее

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

глядя на этот примитив http://e154.ru/blog/post/64

это похоже на что-то еще кроме как философию объектно ориентированого программирования?

*делятся

опиши это как-то иначе, другим словом, но не ооп

просто вот в корне подход

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

интерфейсы это контрактное программирование, при чем здесь ооп

обоже, я пытаюсь до тебя донести саму суть, а ты пытаешься притянуть сюда что-то обратное

весь язык построен

на объектах, которые имеют структуру, состояние и методы

которые между собой взаимодействуют

это и есть корень ооп

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

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

и кстати контрактное программирование не исключает ооп, уж совсем

1) в интерфейсах лучше именованные 2) если идет два подряд значения одного типа - именованные (в интерфейсах) 3) если между декларацией и ретурном больше одного экрана, то а) емкие имена переменных б) никаких именованных ( постоянно придется смотреть что же именно возвращает функция) 4) при комплексной логике и вложенных блоках, именованные могут дать сайд эффект

благодарю, интересно

а госаблаймеры все уже спать пошли, или есть тут еще?

у меня два вопроса