Если вы примете тот факт, что авторы Go занимаются кое-чем другим, чем желанием запудрить вам мозг, мне будет проще отвечать на ваши многочисленные комментарии.
Опять дурака валять начинаете. Вы не отвечаете на мои комментарии, я опять вижу приход слепой веры в праведность и полное непонимание причин дизайна языка. Только то, что так надо и все. Но вы все продолжаете мне отвечать, не давая никакой полезной информации и ответов на вопросы.
Вы предлагает убрать вообще указатели?
Я вообще-то предложил не это, научитесь читать уже посты. Я предложил сделать все указателями как это в Java и C#. Только там разработчик вообще не думает, указатель это или нет. Ему это не важно. У него есть объект, он его передает, вызывает у него методы. Функция может его модифицировать. Все просто и ясно. Можно просто писать код, а не гадать — а не лучше бы мне здесь было указатель всунуть. Не это ли философия языка Go — писать код и просто решать задачу. Выбор это прерогатива С и С++, где с помощью этих больших возможностей решаются задачи, для которых Go вообще не предназначен. В философии Go в этом месте выбора вообще быть не должно — есть один вариант и все. Тоже самое авторы ответили насчет возвращаемых значений — не нужно два варианта, нужен один и все. Таков Go, но уже поздно — 1.0 вышла, код сломается.
Мне не видна вообще ценность этого усложнения языка, однако я по всему интернету вижу вопросы, а что же мне и когда использовать. Это мутная тема Go, указатель или нет в методе структуры — ведь авторы не дают прямо четких наставлений, а так, если структура большая, то все же используйте указатели, даже если метод не модифицирует объект, ибо копирование много кушает. Убрать бы вообще это и не пудрить людям мозг. Его применением видится лишь чем-то вроде const методов из С++, но выглядит скорее таким же бесполезным и вносящим лишнюю путаницу из-за своей же примитивности (в C++ хотя бы есть всякие константные указатели и ссылки). В С++ к этому все привыкли, а видеть такое в Go странно — интересно, задавал ли кто вопрос о причине такого решения. Потому что вполне реально, что объективных причин держать эту фичу кроме как совместимость может и не быть. Как то, именованные возвращаемые значения — фича, которую авторы хотели бы убрать, ибо она лишняя и только усложняет язык, но уже поздно. И таких не одна. С объявлением переменных тоже есть желание убрать лишнее.
Если бы логичность была выше простоты, такого бы не было.
Если бы здесь была простота, то не было бы вообще разделения на значение и указатели, пришедшее из мира совсем не простых С/С++. Все указатель и вперед, как в тех же C# и Java. Либо более радикально, никаких указателей и совместного владения, только передача владения объектом. Существенно упрощает как язык, так и правила работы с ним. Вместо этого в Go мутные правила, когда же нужны указатели, а когда значения. В особенности это касается методов. Мне, честно, не понятно, зачем было введено это усложнение. В Go выглядит несколько неуместным. В некоторых местах у Go есть такие вот шероховатости, которые сильно печалят.
Как вот меня при парсинге печалил такой вот случай
a, err := read(); err != nil {
return err;
}
Когда результат кладешь в переменную, то все красиво. Обе переменные не надо объявлять заранее, просто пишешь код. Как только вместо «a» возникает поле структуры, то err приходится объявлять где-то сверху и использовать обычное присвоение, ":=" не совместим с полями структур. Это логично, но было бы проще это сгладить и позволить писать тот же самый код, а не вспоминать времена С, когда в начале функции у тебя пачка локальных переменных.
Это называется специализация, а не низкий порог вхождения. Зато вот какой-нить сервер на кастомном протоколе я бы начал писать на плюсах, а не PHP. Сокеты, thrift и вперед.
Хех, я, по сути, программирование начал с плюсов. Бейсик и паскаль в школе не считаю как-то, но реальное программирование началось на С++. И, скажу я вам, это было не сложно, хотя программа включала все от и до. И как же я рад, что я начал с этого. Начинать с PHP — мне кажется, что там слишком много инфраструктуры надо понять, прежде чем войти в него. Веб-сервер, хтмл, файловая система хоста, кто и как это все запускает, куда девается это все после закрытия странички, что это за сессии и прочее и прочее. Я сам просто помню все эти вопросы, когда я с этим всем знакомился — это ж совершенно не традиционная модель исполнения кода.
Но оперируем же мы не пустыми интерфейсами (по сути, аналог object), а конкретными типами. Статическая типизация. Просто как-то принято наружу из библиотек выставлять не структуры, а интерфейсы. Вы открыли сокет — вам наружу интерфейс, статический определенный тип. Зачем вам знать, что за структура за ним стоит? Кажется испокон веков такое используется в ООП языках и когда я начал писать на Go мне сразу вспомнилось — да это же как интерфейсы и протоколы в C# и obj-C соответственно. Прям вспоминаются все эти умные книжки, где талдычат — везде наружу выставляем интерфейсы. Ибо слабое сцепление и прочие умные концепции.
Да, я размываю определение ООП до степени концепций, а не конкретных реализаций в любимых языках. Смысл этого? Не знаю, просто дискуссия. Поднята тема ООП в Go, я высказал свое мнение на этот счет. Если почитаете интернеты, то эта тема частенько поднимается. Люди пытаются найти в Go ООП, которое они видели в других языках. В ответ же звучит — Go реализует концепции ООП, но не так, как это делают другие языки. В конечном итоге важны именно концепции и их практическая польза, а не четкость понятий, которые живут только в академических кругах. Вам это сильно не нравится и вы зачем-то мне пытаетесь что-то доказывать. Еще раз, мне не важны определения. Мне важные концепции и в вопросе ООП, которые подняла статья, я имею уже упомянутое мнение.
Что до параметрического полиморфизма. Пожалуйста, кладите в список интерфейсы и вы получите то, что вам надо. Я не понимаю, вам так важно, чтобы все выглядело как в каких-то языках или все таки удовлетворялись идеи определенные? Основная идея полиморфизма — положил кучу объектов не важно какого типа, но реализующих единый интерфейс, в один массив. Все, ты работаешь с ними единым образом. Это полиморфизм и никакие generics тут не нужны. Objective-C как-то прекрасно живет на позиции ООП языка (даже частенько называет более православным, чем С++), но в нем generics нет (недавно появились всего лишь аннотации для компилятора). Это не говоря о том, что вы зачем-то ограничились одним узким примером полиморфизма, да еще дополнительно ограничили его до дженериков.
Вы с языком то знакомы? Полиморфизм достигается через интерфейсы, при этом голыми структурами вообще не принято оперировать. fmt.print функции вкупе с интерфейсом Stringer отлично это используют. Классы, а что есть классы, что их там нет? Наследование? Embedding позволяет «наследовать» все методы, интерфейсы и поля исходного типа, что из-за этих самых интерфейсов позволяет получить в этом случае полиморфизм. При этом есть приватные и публичные поля и методы. Все как по ООП. Мне понятно, что вы цепляетесь к определениям, которые заучили в школе и универе. И Go действительно не ложится на них идеально, но концепции, которые в них заложены, он реализует, а значит и может называться ООП языком. Просто это не C# и Java, вот и все.
Спать я буду спокойно, но меня удивляет такая вот вера в непоколебимость определений ООП, за которыми стоят не концепции, а не какие-то конкретные реализации в языках. Мне вот хочется называть его ООП, потому что таково мое мнение, я вижу концепции ООП в таком свете. Вам так не кажется — можете придумать для Go какие-то другие определения. Не суть важно.
По первому можно ответить словами самих авторов. В Go принято и всячески рекомендуется делать интерфейсы из минимального количества методов вплоть до одного. Тогда проблема уходит само собой. С другой стороны, такой проблем по идее и не должно происходить. Есть метод, есть аргументы — сразу понятно, что он хочет. Библиотеки обычно возвращают интерфейсы, а не голые структуры, что, опять же, снимает эту проблему. А так да, только смотреть на список методов. Иных механизмов язык вроде бы не предоставляет, хотя помощь IDE здесь была бы все таки уместна.
Вот такие статьи по Go и нужны. Ничего против не скажешь.
ООП — это отнюдь не «классы» и «наследование»
Как раз недавно в комментариях в статье про Swift вылезла эта тема. Go и без привычного наследования является ООП языком, а структуры Go вообще не вижу причин не называть классами. Да, есть явно разделение на интерфейс и свойства, но все вместе это дает вполне себе классы — мы создаем объекты, которые имеют методы для работы с ними. Вроде все как у всех. Ну и полиморфизм, что важно, на месте. После протоколов Obj-C и интерфейсов C# все это выглядит вполне знакомо.
Это все какие-то гадания на кофейной гуще. ООП никуда нигде не делось. То, что модные языки немного по-другому его делают, ничего особенно не меняет. Swift в первую очередь мультипарадигменный язык, а что использовать будет пользователь уже его дело, а не Apple. Они просто перенесли все из ObjC и это именно его фишка, а не тренд, потому что им надо вообще сохранять обратную совместимость с их огромным ООП Cocoa. Никто это менять не станет, а значит и из языка это не исчезнет.
Что до Go, то единственная проблема там отсутствие наследования привычного — вместо наследования реализации используется наследование интерфейсов, что тоже вполне обычная вещь. Но все остальные атрибуты на месте в привычном виде — инкапсуляция, полиморфизм, абстракции. Даже можно заключить, что все является объектом, потому что интерфейсы можно реализовать даже для int.
Обычные такие интерфейсы как в том же C# с поддержкой множественного их наследования — действительно удобно и, в общем-то, это ООП как оно есть. Собственно, протоколы это фича, пришедшая из Obj-C — он тоже не ООП теперь? Фишка Go не в том, что там интерфейсы есть, а то, что не нужна их явная реализация. Есть методы — значит реализовал.
Классы никуда не делись и в Go. Там просто нет наследования, но есть встраивание как костыль на замену. Структура с методами и интерфейсами — чем не класс. Никуда классы не денутся и из swift — это обычный мультипарадигменный язык, в том числе ООП, которое там обычное и всем привычное.
Справедливости ради, переход на приватные поля классов только в m файлах для меня только плюсы несет. А публичные поля только через свойства. Это и сокрытие реализации, и очистка интерфейса от деталей реализации. Естественно, рантайм все равно позволит получить все поля класса, где бы они не были.
До сих пор не могут заставить себя перейти на него и даже начать баловаться с ним. Преимуществ самого языка — для меня их нет, objc прекрасно читается и пишется после долгого опыта работы с ним, а фичи меня ничем не подкупают — они ничего не меняют, а отчасти заставят лишь спотыкаться по первости. Все эти дженерики, ноннулаб переменные, хитрые энумы и прочие фенечки — все это забавно скорее для тех, кто начинает со свифта. Ну и конечно для меня ставит крест на любом применение факт нестабильности самого языка и общей глючности всего со свифтом связанного и тот факт, что он до сих пор требует тащить с собой тонну библиотек.
Подозреваю, что свифт слишком молод и сильно меняется, ломая совместимость. Засунуть либы в ось это значит отказаться от обновлений частых и залочить все API — обновления не должны ломать ничего в приложениях, которые скомпилены для старых версий. А с этим у свитф не очень.
Как доживет до стабильно состояния, так и залочат. Тем более сами это говорят.
Так вы может просто уже прекратите это делать? Раз сказали — ладно, сорвались, бывает. Второй раз сказали — ну блин, надо что ли яички уже отрастить, либо просто не бросаться громкими словами.
который так возносит себя над всеми остальными, включая пионеров computer science, унижает их и новые для себя технологии, лишь из-за того, что привык работать с другими технологиями.
И получился более страшный вариант кода с goto на метку cleanup. Так или иначе нужно делать то, что делают деструкторы в С++ и finally, если хочется получить что-то читабельное.
Опять дурака валять начинаете. Вы не отвечаете на мои комментарии, я опять вижу приход слепой веры в праведность и полное непонимание причин дизайна языка. Только то, что так надо и все. Но вы все продолжаете мне отвечать, не давая никакой полезной информации и ответов на вопросы.
Я вообще-то предложил не это, научитесь читать уже посты. Я предложил сделать все указателями как это в Java и C#. Только там разработчик вообще не думает, указатель это или нет. Ему это не важно. У него есть объект, он его передает, вызывает у него методы. Функция может его модифицировать. Все просто и ясно. Можно просто писать код, а не гадать — а не лучше бы мне здесь было указатель всунуть. Не это ли философия языка Go — писать код и просто решать задачу. Выбор это прерогатива С и С++, где с помощью этих больших возможностей решаются задачи, для которых Go вообще не предназначен. В философии Go в этом месте выбора вообще быть не должно — есть один вариант и все. Тоже самое авторы ответили насчет возвращаемых значений — не нужно два варианта, нужен один и все. Таков Go, но уже поздно — 1.0 вышла, код сломается.
Если бы здесь была простота, то не было бы вообще разделения на значение и указатели, пришедшее из мира совсем не простых С/С++. Все указатель и вперед, как в тех же C# и Java. Либо более радикально, никаких указателей и совместного владения, только передача владения объектом. Существенно упрощает как язык, так и правила работы с ним. Вместо этого в Go мутные правила, когда же нужны указатели, а когда значения. В особенности это касается методов. Мне, честно, не понятно, зачем было введено это усложнение. В Go выглядит несколько неуместным. В некоторых местах у Go есть такие вот шероховатости, которые сильно печалят.
Как вот меня при парсинге печалил такой вот случай
Когда результат кладешь в переменную, то все красиво. Обе переменные не надо объявлять заранее, просто пишешь код. Как только вместо «a» возникает поле структуры, то err приходится объявлять где-то сверху и использовать обычное присвоение, ":=" не совместим с полями структур. Это логично, но было бы проще это сгладить и позволить писать тот же самый код, а не вспоминать времена С, когда в начале функции у тебя пачка локальных переменных.
Ее разве отбирали?
Что до параметрического полиморфизма. Пожалуйста, кладите в список интерфейсы и вы получите то, что вам надо. Я не понимаю, вам так важно, чтобы все выглядело как в каких-то языках или все таки удовлетворялись идеи определенные? Основная идея полиморфизма — положил кучу объектов не важно какого типа, но реализующих единый интерфейс, в один массив. Все, ты работаешь с ними единым образом. Это полиморфизм и никакие generics тут не нужны. Objective-C как-то прекрасно живет на позиции ООП языка (даже частенько называет более православным, чем С++), но в нем generics нет (недавно появились всего лишь аннотации для компилятора). Это не говоря о том, что вы зачем-то ограничились одним узким примером полиморфизма, да еще дополнительно ограничили его до дженериков.
Спать я буду спокойно, но меня удивляет такая вот вера в непоколебимость определений ООП, за которыми стоят не концепции, а не какие-то конкретные реализации в языках. Мне вот хочется называть его ООП, потому что таково мое мнение, я вижу концепции ООП в таком свете. Вам так не кажется — можете придумать для Go какие-то другие определения. Не суть важно.
Как раз недавно в комментариях в статье про Swift вылезла эта тема. Go и без привычного наследования является ООП языком, а структуры Go вообще не вижу причин не называть классами. Да, есть явно разделение на интерфейс и свойства, но все вместе это дает вполне себе классы — мы создаем объекты, которые имеют методы для работы с ними. Вроде все как у всех. Ну и полиморфизм, что важно, на месте. После протоколов Obj-C и интерфейсов C# все это выглядит вполне знакомо.
Что до Go, то единственная проблема там отсутствие наследования привычного — вместо наследования реализации используется наследование интерфейсов, что тоже вполне обычная вещь. Но все остальные атрибуты на месте в привычном виде — инкапсуляция, полиморфизм, абстракции. Даже можно заключить, что все является объектом, потому что интерфейсы можно реализовать даже для int.
Классы никуда не делись и в Go. Там просто нет наследования, но есть встраивание как костыль на замену. Структура с методами и интерфейсами — чем не класс. Никуда классы не денутся и из swift — это обычный мультипарадигменный язык, в том числе ООП, которое там обычное и всем привычное.
Как доживет до стабильно состояния, так и залочат. Тем более сами это говорят.
Так вы может просто уже прекратите это делать? Раз сказали — ладно, сорвались, бывает. Второй раз сказали — ну блин, надо что ли яички уже отрастить, либо просто не бросаться громкими словами.
Врать не хорошо. Обижаться можно и молча.