там все православно, все есть объект, все четенько с прототипным наследованием, намного более гибкая хрень, есть настоящая инкапсуляция (а не кастыли как в плюсах), есть настоящий полиморфизм... Я конечно понимаю что ты просто набрасываешь но в JS от ООП больше в разы чем в Java

про инкапсуляцию это замыкание или weakmap?

про инкапсуляцию это замыкание или weakmap?

замыкания конечно, weakmap это кастыли

но люди же спрашивают, они явно не имеют ввиду твое крутое ооп)

замыкания конечно, weakmap это кастыли

лол)

лол)

сча ты меня начнешь учить что "потечет же"

заменили на костыль получается

ну weakmap он жеж не совсем для этого вводился

например на нем оч удачно можно запилить identity map

и мне оч не хватает возможности заюзать оный в php внутрях ORM какой

(хотя всегда можно поставить экстеншен)

я не знаю о каком ты полиморфизме в жавасрипте

что строку можно к интеджеру плюсовать? :)

я не знаю о каком ты полиморфизме в жавасрипте

ой да ладно там же внутрях все на late binding и ты можешь в рантайме подменять реализацию с тем же интерфейсом на раз два)

вплоть до нарушения полиморфизма

ну и да, лямбды всякие и всякие приколы оттуда же вроде каррирования и partial apply сильно позволяют упростить код

на раздватри

вплоть до нарушения полиморфизма

хочешь хорошо - делай хорошо

лямбды и каррирования - это не про ооп

в каком бы смысле ты его ни понимал)

лямбды и каррирования - это не про ооп

бля Коль, ты определись уже

решил что термин ООП бесполезен - так прекращай его использовать либо давай ссылку на свое определение

полиморфизм тоже не про ООП)

как и инкапсуляция

как и наследование

и что?

когда люди спрашивают типа "хорош ли ооп в жаваскрипте", то явно имеется ввиду классо-ориентированное программирование, а не выдержки из ФП

КОП

когда люди спрашивают типа "хорош ли ооп в жаваскрипте", то явно имеется ввиду классо-ориентированное программирование, а не выдержки из ФП

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

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

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

я о сути

а не о внутренностях.

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

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

проблема с классами в том что они существуют только в компайл тайме

(мы же признаем что статика не имеет отношения к ооп? даже с классами))

хз с чего ты это взял

хз с чего ты это взял

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

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

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

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

типы это не про ооп

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

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

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

есть же слотовое наследование, есть прототипное

проблема с классами в том что они существуют только в компайл тайме

А в жс класс это объект

А в жс класс это объект

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

в python к слову тоже

и в пхп, не переживайте)

и в пхп, не переживайте)

отсыпь аа?

и в пхп, не переживайте)

Нет же

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

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

ну мол объясни мне что такое наследование, для чего оно нужно, как должно работать. Представь что я понятия не имею что там как в этих ваших джавах

объясни для чего придумали эту концепцию?

даже если мы говорим об ООП как об инстансах классов - мы всеравно наблюдаем здоровенный семантический разрыв

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

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

насколько малой? насколько полиморфное?

самой малой, которой это можно сделать, если тип у тебя определяется набором пропертей

самой малой, которой это можно сделать, если тип у тебя определяется набором пропертей

опять ты к типам привязался

забудь о них на секундочку

просто забудь.

забудь про физику и обьясни мне почему яблоко падает ньютону на голову? :)

вся суть классов как раз в том, что это типы

ну или объясни что ты с этими типами так трясешься?

так

давай с самого начала

ну смари, на пальцах и с самого начала

почему у нас изначально в 67-ом или в каком там году появились классы?

зачем компилятору нужно было знать типы?

давай не будем в историю, потому что там много чего творилось, и люди не боги

и как это относится к вопросу что у тебя был килобайт оперативки и это было охерительно?

лол

давай не будем в историю, потому что там много чего творилось, и люди не боги

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

погоди, то есть ты хочешь свести современное программирование к килобайту оперативки?

это очень грустно, как история про присвоить и равно

погоди, то есть ты хочешь свести современное программирование к килобайту оперативки?

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

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

тогда давай еще раньше, к тьюрингу

тогда давай еще раньше, к тьюрингу

тьюринг и черч, все клево

тыж знаешь историю про присвоение := и равно =, и почему в сях равно вместо присвоения?

хотя это днище

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

потому что память экономили

а не от большого ума)

именно так

ну мол объясни мне что такое наследование, для чего оно нужно, как должно работать. Представь что я понятия не имею что там как в этих ваших джавах

можно я попробую объяснить. Наследование нужно для того чтобы оптимизировать логику декораторов которые в случае композиции будут создавать отдельные объекты в рантайме. Допустим у нас есть класс DBConnection объект которого представляет собой соединение с базой данных. Применяя композицию обычно создают отдельный класс Repository который представляет собой crud-операции с таблицами базы данных, который в конструкторе создает new DBConnection(...) и использует его для взаимодействия c базой данных. А вот применяя наследование вместо композиции класс Repository отнаследуется от DBConnection и добавит нужный код работы с crud просто добавив нужные методы. И здесь принципиальное отличие — в случае композиции при создании объекта Repository будет создано два объекта в рантайме (сам Repository и объект DBConnection) а применяя наследование — только один объект. А в случае если у на будет цепочка из 10 различных сущностей которые что-то добавляют и переопределяют то с композицией это уже 10 рантайм-объектов а с наследованием только один вне зависимости от длины этой цепочки (да хоть тысячу сущностей). Или другой пример - хокки реакта. Если их делать через композицию то список из тысячи компонентов на которого навешаны 10 хокков выльется в создании 10 тысяч объектов при каждом рендере и потом реакт будет diff-ать 10 тысяч компонентов. А с наследованием - будет только тысяча объектов и сравнивать реакту нужно будет только тысячу компонентов. В этом и суть наследования — оно позволяет вынести в compile-time много работы экономя cpu-циклы и память

можно я попробую объяснить. Наследование нужно для того чтобы оптимизировать логику декораторов которые в случае композиции будут создавать отдельные объекты в рантайме. Допустим у нас есть класс DBConnection объект которого представляет собой соединение с базой данных. Применяя композицию обычно создают отдельный класс Repository который представляет собой crud-операции с таблицами базы данных, который в конструкторе создает new DBConnection(...) и использует его для взаимодействия c базой данных. А вот применяя наследование вместо композиции класс Repository отнаследуется от DBConnection и добавит нужный код работы с crud просто добавив нужные методы. И здесь принципиальное отличие — в случае композиции при создании объекта Repository будет создано два объекта в рантайме (сам Repository и объект DBConnection) а применяя наследование — только один объект. А в случае если у на будет цепочка из 10 различных сущностей которые что-то добавляют и переопределяют то с композицией это уже 10 рантайм-объектов а с наследованием только один вне зависимости от длины этой цепочки (да хоть тысячу сущностей). Или другой пример - хокки реакта. Если их делать через композицию то список из тысячи компонентов на которого навешаны 10 хокков выльется в создании 10 тысяч объектов при каждом рендере и потом реакт будет diff-ать 10 тысяч компонентов. А с наследованием - будет только тысяча объектов и сравнивать реакту нужно будет только тысячу компонентов. В этом и суть наследования — оно позволяет вынести в compile-time много работы экономя cpu-циклы и память

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

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

> Наследование нужно для того чтобы оптимизировать логику декораторов которые в случае композиции будут создавать отдельные объекты в рантайме. давай рассмотрим какой-нибудь пример и посчитаем сколько у нас памяти отъест композиция и сколько мы сможем ужать в наследовании

реализация наследования - это тоже не его суть, зачем нам знать как оно внутри?

реализация наследования - это тоже не его суть, зачем нам знать как оно внутри?

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

потому, что его делали не для какой - то "сути", а я решения проблемы

реализация наследования - это тоже не его суть, зачем нам знать как оно внутри?

все хотели композицию но не хватало оперативки

то есть, не сначала придумали, а потом сделали, а наоборот

ну это я утрирую

но общая идея, думаю, ясна

то есть, не сначала придумали, а потом сделали, а наоборот

вообще тут надо смотреть че там было в симула

ну да, можно уходить дальше в историю

Алан Кей писал что наследование на момент создания смолтока было для него непонятной и странной штукой и он от него отказался

может концепты были и раньше (наверняка)

но success story наверняка сложился типа "давайте тут экономить будем - а смотрите, получилось похоже"

http://heim.ifi.uio.no/~steinkr/papers/HiNC1-webversion-simula.pdf