имеет, но может иметь разные проявления

коллега, или вы свое определение ООП тут приведете, или я вас отпралю в RO на сутки

имеет, но может иметь разные проявления

это не так в случае с наследованием, к сожалению

коллега, или вы свое определение ООП тут приведете, или я вас отпралю в RO на сутки

ну или прекратите эту беседу поддерживать

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

ну или прекратите эту беседу поддерживать

выбираю этот вариант

спасибо!

Нет, ну вот, блин, интересно! Ну все, блин, обсуждают как что-то не так, как везде. Просто забили на отправные идеи авторов языка, или даже не дали себе труда вникнуть, и обсуждают просто взахлеб! А нафига? :)

не дали труда

в случае с ООП - не дали себе труда вникнуть ни в ООП, ни в go

не хотел заваривать этот холивар снова)

Ну и правильно. Не для чего!

на самом деле - вопрос не такой простой и не такой бесполезный

у большинства тех, кто работает в индустрии каша.

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

и запинить как библию в конфу

у некоторого количества - в голове неоправданный фашизм

у некоторых персонажей что-то вроде понимания, но ориентируются они в них интуитивно

это самый лучший из наблюдаемых вариантов.

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

он очень похож на кашу, но ничего лучше у нас нет

/me сделал флудилку freenode.net#go-go. Welcome! :)

и, в принципе, разговоры о парадигмах и подходах могут вести от каши к "чему-то вроде понимания"

но для того, чтобы вели - надо их вести разумно, а не эмоционально

и, в принципе, разговоры о парадигмах и подходах могут вести от каши к "чему-то вроде понимания"

К чему-то вроде понимания может вести системное обучение или исследование (что почти одно и то же). А бессистемные разговоры - не могут

"в go нет ООП" - начинаем с определений. (тут выяснится, что у go есть определение, а у ООП нет, и это будет первый шаг)

но для того, чтобы вели - надо их вести разумно, а не эмоционально

👍

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

Если в блокноте рисовать, то можно графически изобразить пивной ларек из 70-х, длинную очередь небритых мужиков, а внутри сидит тетя Клава, события обрабатывает...

а может это возможно отобразить на диаграмах протоколов?

как событие общается с очередью, но там все равно не хватит места - надо где-то дописывать информацию о сообщениях например

а может это возможно отобразить на диаграмах протоколов?

да

События и их обработка - это вобще целая отдельная диаграмма

да

бл* нет, нельзя, я перепутал

google 4 sequence diagram

оно же и имелось в виду

ок, но судя по гуглу они выглядят по-другому

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

ну единственный внятный способ документировать flow - это UML

при этом важно понимать, что UML - это очень разнообразное явление

например, блок-схемы - подмножество UML

и диаграммы протоколов - тоже

тогда нужно постигать uml, пойду погуглю книжки

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

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

Собственно все так делают

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

Мне кажется вы совсем издалека зашли

Дальше было бы, еслиб вы пошли постигать UML... Ой, вы же пошли постигать UML :\

Вещь полезная, но скорее факультативная

надо сказать, что UML в процессе создания ТЗ используется очень редко

в основном потому, что обычно не понятно, что именно мы строим, пока мы не построим терть минимум

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

По крайней мере для себя смысла не видел

ну в моем понимании - надо сначала понять, а потом писать

Как то в процессе написания кода думается лучше

хотя бы большими мазками понять

ну в моем понимании - надо сначала понять, а потом писать

ну я понимал думая, диаграмы мне не сильно помогали

Они, скорее, время отнимали

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

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

Удобно UMLем документировать существующий бизнепроцесс, когда например доки нет или устарела

Есть тз ,создать доски объявление есть писать на гоу сколько время я трачу ? Выбрать гоу или пхп ?

А вообще да, особо не пригождается

Есть тз ,создать доски объявление есть писать на гоу сколько время я трачу ? Выбрать гоу или пхп ?

Эрланг выберите, я не знаю. Так себе вопрос

Есть тз ,создать доски объявление есть писать на гоу сколько время я трачу ? Выбрать гоу или пхп ?

Попробуйте хаскель

Эрланг выберите, я не знаю. Так себе вопрос

Маа шш

Маа шш

Они прикалываются над тобой, не слушай их, пиши на Си

подскажите, сюда можно постить вакансии по go?

подскажите, сюда можно постить вакансии по go?

Это сюда @gogetajob

Это сюда @gogetajob

thx

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

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development Крэга Лармана годная. Рекомендую к прочтению)

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

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

рекомендую draw.io

рекомендую draw.io

Подписываюсь.

Подписываюсь.

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

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

Помогает, когда разработают большой проект

Попробуйте plantuml

Его можно прямо в визуал студио в виде плагина

Пишешь небольшой код, он тебе схемы

стоит ли хранить в context value юзера полученного с бд в миддлвейр?

стоит ли хранить в context value юзера полученного с бд в миддлвейр?

избегайте context value по возможности, передавайте что-либо через ctx value только в случае если вам приходится передавать сиё через сторонние библиотеки, например: ваш network -> 3-rd party GraphQL library -> ваш resolver function (в этом случае без context value не обойтись, ибо соторняя библиотека посредник, которая вызывает ваши функции, не знает ничего о тех данных, которые вы хотите через неё передать)

Guys, need your opinion on that: Should non-const types be automatically (implicitly) converted to const types? This is without implicit non-const to const conversion: var mut2immut * const Object = const(&Object{}) var immut2mut const * Object = &const(Object{}) var immut2immut const * const Object = const(&const(Object{})) func NewConstSlice() const [] * const Object { return [] * const Object { &const(Object{}), &const(Object{}), } } This is with implicit non-const to const conversion: var mut2immut * const Object = &Object{} var immut2mut const * Object = &Object{} var immut2immut const * const Object = &Object{} func NewConstSlice() const [] * const Object { return [] * const Object { &Object{}, &Object{}, } } Do you think that implicit non-const to const conversion is safe? (bearbeitet)