это вранье

Оно есть, но не такое как везде

это вранье

наследование в студию

Оно есть, но не такое как везде

значит это не ооп

всё просто

наследование в студию

кто вам сказал, что наследование - это ООП?

значит это не ооп

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

кто вам сказал, что наследование - это ООП?

никто, наследование это часть ООП

необязательная

Это обязательное ?

А что если я скажу что я писал на сях в ООП стиле

В сях есть ООП?

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

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

В сях есть ООП?

нет

Но я писал в ООП стиле. Где же истина ?

ООП-стиль ≠ ООП

зачем вы смешиваете понятия

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

это скучный разговор, и он примерно раз в квартал происходит, но давайте еще раз ваше определение ООП в студию

@kezvision мсье, прошу https://m.habr.com/post/225907/

разговор не то что скучный, он бессмысленный

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

разговор не то что скучный, он бессмысленный

+1

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

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

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

В любом языке нет ничего в том же виде, в каком оно есть "везде". Вот что я имел в виду :)

коллеги, я вас прошу

anyway, я нигде не говорил, что отсутсвие наследования это плохо

хотите это мусолить - делайте это хотя бы формально в рамках

хотите это мусолить - делайте это хотя бы формально в рамках

А чего такого? Я даже слово на букву g не употребил :)

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

слово на букву g, как мы понимаем, к oop не имеет отношения

слово на букву g, как мы понимаем, к oop не имеет отношения

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

например, через интерфейсы

слово на букву g, как мы понимаем, к oop не имеет отношения

Ну, это смотря какое слово. Некоторые слова на букву g имеют отношение к языкам на букву j, например. Но мы таких слов не употребляем :)

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

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

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

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

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

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

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

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

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

спасибо!

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

не дали труда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

?

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

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

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

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

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

да

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

ERROR: S client not available

да

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

google 4 sequence diagram

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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