а не кажется что топить против функциональщины или ооп - это срач годов с 80-х?)

Это не поможет, потому что типизация абсолютно разныя.

а не кажется что топить против функциональщины или ооп - это срач годов с 80-х?)

нет, это вечный срач

а не кажется что топить против функциональщины или ооп - это срач годов с 80-х?)

Не кажется. Есть конкретные доводы против ООП в js/ts

нет, это вечный срач

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

да и в джаву лямбды завезли

Я календарь переверну...

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

Не кажется. Есть конкретные доводы против ООП в js/ts

что за доводы?

бля

а не кажется что топить против функциональщины или ооп - это срач годов с 80-х?)

Вот бы еще выяснить что такое ооп и фп

выкиньте нахуй свои привычки, если лезете в жс

вот вам итог

только наследование на прототипах - только хардкор)

Если я не ошибаюсь, тои на бекенде вас нахуй пошлют, если вы наследоваться захотите.

Что бы тут функциональщики не говорили, но JS мультипарадигменный язык, а значит ООП тут не запрещено.

Только интерфейсы и композиция.

Если я не ошибаюсь, тои на бекенде вас нахуй пошлют, если вы наследоваться захотите.

Ошибаешься

Что бы тут функциональщики не говорили, но JS мультипарадигменный язык, а значит ООП тут не запрещено.

не запрещено

но оно и работает не так как в других языках

и цена другая

Ошибаешься

Ну, значит у нас особый бекенд.

и цена другая

Видел проект с дичайшим ООП?)

Я вообще топлю за правильное смешение ФП и ООП

а в го есть наследование?

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

а в го есть наследование?

нет

Видел проект с дичайшим ООП?)

видел

и с ооп

и с наследованием в ооп

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

и с цепью виртуальных методов

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

Потому что потом задолбаешься это говно разбирать.

видел

Точно с ооп?)

Точно с ооп?)

может ты мне расскажешь что такое ооп?

или мне открыть objc проект и показать? (бля,не смогу)

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

В Go нет наследования. И мне это в моём игрушечном проекте уже аукнулось.

может ты мне расскажешь что такое ооп?

Вряд ли, сам все хочу узнать

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

А в лиспе! *шуткаминутка в сраче*

В Go нет наследования. И мне это в моём игрушечном проекте уже аукнулось.

а зачем тебе наследование?

а зачем тебе наследование?

затем.jpg

А в лиспе! *шуткаминутка в сраче*

Ммм, у нас в универе было

может ты мне расскажешь что такое ооп?

это эффектор

как будто что то новое

затем.jpg

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

это эффектор

ага

лол

а зачем тебе наследование?

Мне в одном месте хотелось бы, чтобы базовый класс владел информацией, которая появляется только в классе-потомке.

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

Ах если бы было всё так просто.

Мне в одном месте хотелось бы, чтобы базовый класс владел информацией, которая появляется только в классе-потомке.

Фу, наследование реализаций

Мне в одном месте хотелось бы, чтобы базовый класс владел информацией, которая появляется только в классе-потомке.

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

Вот видите какие костыли пошли. Декораторами надо.

А в Go нет декораторов

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

это первое что в голову пришло

А в Go нет декораторов

я поэтому написал паттерн

а не синтаксис

Мне в одном месте хотелось бы, чтобы базовый класс владел информацией, которая появляется только в классе-потомке.

Тогда он в состоянии взять что ему нужно из потомка напрямую

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

Что весьма костыльно

Тогда он в состоянии взять что ему нужно из потомка напрямую

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

Фу, наследование реализаций

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

И вообще не стоит впадать в крайности.

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

а почему ты не можешь передать при создании объекта?

один раз

Ну то есть фактически самому реализовать то самое наследование

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

Ну то есть фактически самому реализовать то самое наследование

Это включение, а не наследование

Ну то есть фактически самому реализовать то самое наследование

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

Это включение, а не наследование

Да, вот только оно будет вести себя в точности как наследование

Наоборот

Наследование будет вести себя как включение

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

Единственное отличие будет в том, что всё это будет реализованно руками, а не компилятором

Да, вот только оно будет вести себя в точности как наследование

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

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

а виртуальные методы как разрулишь?

class Child {} class Parent { child: Child }

Вжух! Чтение свойств наследника из базового класса

а виртуальные методы как разрулишь?

class Child { doSmth() {} } class Parent { child: Child doSmth() { this.child.doSmth(); } }

class Child { doSmth() {} } class Parent { child: Child doSmth() { this.child.doSmth(); } }

ии

только это не разруливание

вообще ни разу

class Child {} class Parent { child: Child }

Feel the difference, как грится

виртуальные методы немного не так работают (в плюсах по крайней мере)

и как же они работают?

в зависимости от типа

Child foo = new Parent() foo->doSmth() будет вызван у чайлда

кто-то тут запутался, и скорее всего это я

и есть ещё несколько кейсов динамической диспетчеризации которые я не вспомню сходу

тут наоборот надо Parent *foo = new Child(); foo->doSmth();

это же каким умным нужно быть что со всем этим программировать

Обычным

да не гением точно

тут наоборот надо Parent *foo = new Child(); foo->doSmth();

пошел проверять