Языку программирования Rust исполнилось 10 лет

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

Интересное мнение. Чем обоснуете?

а ничем. аксиомы доказывать не требуется.:)

обобщенные функции существуют сами по себе, и не относятся к ооп. можете добавить их в любой язык(где вообще есть функции) и наслаждаться.

а вот динамический полиморфизм вне ооп(ну или его уродливого подобия навроде руста) не существует!

Да я в принципе до сих пор не понимаю разницы между «правильным» и «неправильным» ООП, если честно.

Секретик правильного ООП очень прост: его не существует.

Да я уже с этим смирился. Главное что работать с классами удобнее, чем чисто процедурно. А что на самом деле у меня ООП в моем луа и расте нету - ну..бывает.

Я так понимаю, там чисто внутренние какие то специфичные различия.

обобщенные функции существуют сами по себе, и не относятся к ооп.

Но есть и хорошие новости, например, я на вашу способность улавливать новые концепции особо и не рассчитывал.

Но есть и хорошие новости, например, я на вашу способность улавливать новые концепции особо и не рассчитывал.

я не психиатр, чтобы улавливать «новые концепции» поциентов.

Да я в принципе до сих пор не понимаю разницы между «правильным» и «неправильным» ООП, если честно. Мне и в луа и в раст хватает «ООП». Отлично все оформляется в объект и используется. Удобно, просто.

Я не про синтаксис и семантику, а про то, что они умудряются хоронить старые классы и вместо них запихивать новые. Эта мода у них ещё с первых лет пошла.

правильный ооп - это простой, наглядный, неизбыточный способ описания задачи и ее реализации. правильный ООП только один.

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

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

Но у С++ есть и хорошие стороны. Ну или раньше были.

Так он же везде одинаковый. Разница в синтаксисе, да и то.. Плюс минус 2-4 строки везде и все.

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

и ведь никогда не знаешь

огурцы

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

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

Так я о том и говорю, что парадигма везде одинакова. Ну разве что в раст нет наследования и все.

В расте основа для предметной декомпозиции взята из функциональщины. Это алгебраические типы + трейты(классы типов) +дженерики(парметрический полиморфизм)+функции высших порядков. Это сейчас наиболее гибкий и мощный подход для декомпозиции, функциональщики шарят. ООПой, соответственно, так вот заморачиваться смысла особого нет, это вообще рекламный баззворд 30-40 летней давности, устаревший и тупиковый. В минимальной полезной форме раст его поддерживает; наследование реализации это вообще антипаттерн, поэтому и имитировать его тоже не надо. Даже наследование только для полиморфизма(подтипирование), тоже так себе идея

угу. уж видел много раз как растоманы просто тупо имитируют классы из с++ или жавы, размазывая растовую кашу по тарелке. и ничего вашего «нового» там не прослеживается.

причем то же самое, но на си++ было б короче записано раза в полтора.

а писать, как не на си++, они не умеют.

там где явщики/плюсовики просто пишут класс, растаманы пишут struct, а потом принимаются ему методы снаружи навешивать.

еще хуже когда для struct пишут соотв. трейт! чтобы почти окончательно уподобиться классам в плюсах.

Главное что работать с классами удобнее, чем чисто процедурно.

Вот так открытие. Как жаль, что в расте их нет, как и в луа, и приходится пардон пердолиться через костыли.

А если все жестко учесть и ограничить, как в раст, тогда какая длина будет?

Ну, у тебя нет, а мне не лениво прописать лишнюю строку с объявлением метатаблицы. Это ж так сложно.

И да, открытие. У меня 2 года ушло на это открытие, пока дошло. Это нигде не объясняют нормально. Такое ощущение, что везде наоборот пытаются мешать в освоении ООП и специально запутывают.

Карбон.

https://github.com/carbon-language/carbon-lang

наследование реализации это вообще антипаттерн, поэтому и имитировать его тоже не надо

А потом у вас нет гуи тулкита, и приходится пробавляться чужими антипаттернами. Это кстати касается всей функцианальщины, но другие хотя бы не претендуют на системность. Что характерно, для C объектные модели и тулкиты есть. Функцианальщики же абсолютно беспомощны за пределами планеты розовых факториалов.

В минимальной полезной форме раст его поддерживает; наследование реализации это вообще антипаттерн, поэтому и имитировать его тоже не надо

«наследование реализации» - это буззворд. придуманный халявшиками от «ленивой типизации». На самом деле это наследование «множества состояний» или области определения базового класса.

Но клоуны-евангелисты от растов и прочих - этого понять не могут.

Наследование - это наследование множества состояний(области определения) и функционала базового класса! а не «реализации».

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

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

А если все жестко учесть и ограничить, как в раст, тогда какая длина будет?

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

а мне не лениво прописать лишнюю строку с объявлением метатаблицы

Дело не в лени (хотя это тоже имеет значение), а в том что класс формально никак не определен. Классов как бы нет, но они всем нужны, в результате бардак: несовместимые реализации, херня в стектрейсах, отсутствие фич. И вот кодер вместо того, чтобы написать class Foo(Bar) городит портянки уникальных костылей. Вот покажите наследование в расте. У каждого умника будет какая-то своя дрисня.

Ну что значи не определен? Определен точно так же, как везде.

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

То что он не описывается словом «класс», мне как то по барабану. Я же знаю, что вот это слово у меня - класс. Мне хватает. У него есть методы? Есть. Они видят все входящее в класс? Видят. Инкапсуляция есть? Есть. Композиция есть? Есть. Даже наследование есть, будь оно неладно.

Чего тебе надо то еще? Чтобы было конкнетно слово «класс»?

Разделил родителя на шесть разных классов и композицией добавил куда надо.

ну вот возьми либу QT и нарисуй ее без наследования. при этом каждый конечный контрол(типа treeview) будет графическим окном, и прочими классами из иерархии на с++, но у тебя иерархии то нет, потому предложи метод.

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

композиция в принципе не отвечает на вопрос об иерархии понятий. то есть на понятиям животное, млекопитающее, кошка, собака, композиция не имеет отношение.

потому что «собака есть животное», но не «включает в себя животное».

Я в принципе до стартового понимания концепции ООП пришел пару месяцев назад. Пока потихоньку разбираюсь чего и куда.

У меня нет компетенции и понимания продолжать диалог.

там и школьник поймет.

есть три основных отношения у классов - является(наследование), состоит из (композиция), зависит (зависимость)

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

усьо. как только это понял, понял половину ООП. другая половина это полиморфизьм.

Да-да! Как-то так оно и воспринимается!.. :)

всегда

зы. приятно когда молодёж

ООП к структурному как фэнтези к сцай фаю

есть набор белетристики об истории софт-хард ОЙти от Ахмеса и до ща

так 70ые 80ые 90ые разно модные

ООП(особенно конца 80ых) это больше евангелизм и продажа серебляных пуль и змеиного молока ибо япи-эпоха

в идеальном мире всё есть как и в Принципе который в Москва-махазин

зы. за сертификатами соответсвия ооП к А.Кею

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

«там» глобальней эффект

проистекающие из различия trade vs craft

проще посмотреть как реализованно расширение типов в Oberon'це

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

есть атд и был хайп

так вот ооп это хайп маркетолухов

по хорошему в «нестоящем ооп» обязана быть мульти(поточно-процессность-конкурентность) из коробки - иначе обмазывание в «семафоры»

Ну если опираться на мнение того кто придумал этот термин, то есть Smalltalk с «правильным» ООП.

Ответом на ваше сообщение я отвечу сразу всем. Потому что могу.

ООП это парадигма, концептуальная схема если по-простому. В ее рамках можно говорить о различных моделях постановки проблем и способах их решения. Какие-то модели больше покрывают предметную область, какие-то меньше, но нет единой «правильной» реализации.

Вторая проблема нахождения невыносимой четкости бытия ООП реализации состоит в том что из-за повсеместного использования абстракций граница самого понятия объект довольна размыта. Ведь что такое объект? Это просто экземпляр класса в памяти.

И получается, что даже создание переменной определенного типа, например строкового - это тоже объект. Ведь реализация типов данных также является классом в котором определяются допустимые операции над этими данными. А значит, любой язык в котором есть хотя бы объявление переменных определенных типов, не говоря о присвоении им данных, также входит в парадигму ООП языков. Живите теперь с этим :)

Весь это спор на кучу страниц просто не имеет смысла.

Ведь что такое объект? Это просто экземпляр класса в памяти.

это ужение на классическую

Объект это всякое которое Субъектом «опрашивается» «с какого оно раёна » и прочие дрыганье

были(измышлены когда памяти(на лентах) стало достаточно для учётных задач) структуры - это локальность по данным

потребовалась распределённость по поведению - но мульти"поточность" была ещё сырой

Субъектно ориентированное программирование так точнее называть те «наративы» о шлющих друг друга сообщениях

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

Ну-ну. Квадрат является прямоугольником или ромбом? От чего будешь наследоваться? Как реализуешь метод прямоугольника set_dimensions(a, b) или ромба set_angle(a)?

справедливости ради

«дэти запомните сол и мол пишутся с мягким знаком а тарелька и вилька бЭз. нэ пэтайтсь понять это нужно запомнить» ортогонально русска язычка

так и к ООП наследование фигурин пример еретичного евангелизма :)

Ну-ну. Квадрат является прямоугольником или ромбом?

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

именно по причине таких вот вопросов.

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

Если уж повторять плюсовое наследование, то с таблицей функций.

Аля

struct A {
  int a;
  int (*value)(struct A *);
};

static int _A_value(struct A *self) {
  return self->a;
}

struct A A_new() {
  return (struct A){
      .value = _A_value,
  };
}

struct B {
  struct A parent;
  int b;
};

static int _B_value(struct A *parent) {
  struct B *self = (struct B *)parent;
  return self->parent.a + self->b;
}

struct B B_new() {
  return (struct B){
      .parent.value = _B_value,
  };
}

int a_value(struct A a) {
  return a.value(&a);
}

int test() {
  struct B b = B_new();
  b.parent.a = 3;
  b.b = 4;
  return a_value(b.parent);
}

На что clang повертит у виска и выдаст:

test:
        ret

варианты четырехугольника

Ну хорошо, пускай у нас будет четырёхугольник с методами set_edges(a, b, c, d) и set_angles(a, b, c, d). Легче стало?

четырехугольник однозначно задается координатами четырех вершин. а не какими то там «углами».

если вам охота иметь какие-то там «квадраты» и «ромбы», вы можете написать функцию «фабрику_квадратов» например, которая будет делать 4угольники являющиеся квадратами. или ромбами. но таких классов не будет.

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

Ну то есть наследование нафиг не нужно?

<плоский> четырёхугольник

и если вспомнить Mother of All Demos

то если в реализации констрейн-движёк то варианты задания с реакцией на «не евклидовые» и не плоские четырёстороники

зы. тетраэдр - четверовершиник

вабщет четверовершиник

это если все четыре в плоскости то оказыца четырёхстороник(плоскый)

и да в каком количестве(и вообще в каком из сортов)координат вы намерены задавать четырёх-чёто-тамник?

не однозначно

важен ещё порядок обхода

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

Ну то есть наследование нафиг не нужно?

нужно конечно. вам сюда

https://ru.wikipedia.org/wiki/%D0%A2%D0%B0%D0%BA%D1%81%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D1%8F

вабщет четверовершиник

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