вряд ли здесь какой-то rustоман будет утверждать, что там есть ООП

Не, ну можно попробовать, просто в целях флейма: ООП - это святая троица «полиморфизм, инкапсуляция и наследование»; полиморфизм в Rust есть, инкапсуляция тоже, и даже наследование есть - наследование трейтов (ведь святая троица ничего не говорит о том, какое именно наследование должно быть). Так что Rust - ООП-язык %)

Наследование реализаций для ООП не обязательно.

Тогда какой смысл в наследовании?

Формального определения, насколько я знаю, нет.

Если не договориться не терминах и определениях, тогда разговор теряет смысл.

Опять пришли к тому с чего начали, это средство называется модуль, и Rust гарантирует что ты не сможешь изменить состояние обьекта за пределом его модуля. Значит и состояние и поведение будут всегда находится в одном модуле как «единая сущность».
Вот я набросал пример улитки, можешь попробовать заставить ее полететь:
https://is.gd/nhpP3X
Если получится, пиши.

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

А разве инкапсуляция не противоречит системе трейтов? Вот выше red75prim показал пример со структурой S. Если для реализации некоторого трейта T нужен доступ к приватному полю S, то что? Вынесение ацессора для этого поля в некий public_interface будет означать отказ от инкапсуляции.

С точки зрения какого-нибудь smalltalk-а там и не ООП вообще, в отличие от современного догмата «ООП = классовая модель + троица».

Боюсь, вы попутали SmallTalk с Self-ом и JavaScript-ом, емнип, в SmallTalk все нормально с классами, и со святой троицей. Кроме того, лично я вообще ничего про классы не говорил, ограничивая ООП только наследованием, инкапсуляцией и полиморфизмом.

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

Этого в расте нет, точка.

А я, кажется, понял, о чем он - методы структуры не описываются в теле struct.

У нас тут поведением и состоянием что обладает? Какая сущность какого типа?

Если для реализации некоторого трейта T нужен доступ к приватному полю S, то что?

То пишем реализацию внутри модуля M, или отправляем PR на реализацию трейта, если модуль чужой.

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

Нет, не является. Твоё школьное определение инкапсуляции обладает нулевой практической ценностью, а наследование реализации успешно (пусть и не всегда с лёгкостью) заменяется композицией.

У Вас ООП головного мозга, пишу на golang не чувствую дискомфорта.

У нас тут поведением и состоянием что обладает?

Модуль.

Какая сущность какого типа?

А где написано что у сущности должен быть тип? Ты пытаешься натянуть на определение инкапсуляции свойства класса, хотя совсем не обязательно иметь класс чтобы получить инкапсуляцию.
P.S. Жду свою летающую улитку.

Если для реализации некоторого трейта T нужен доступ к приватному полю S, то что?

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

Покажи как ты будешь организовывать доступ к приватному полю в c++, не применяя грязные хаки?

Модуль

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

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

Попробовать-то можно, но собеседник всё равно будет считать, что ООП это «как у меня в С++/Java/C#». Такие и JS за ООП язык не считают, чего уж там расту.

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

Отлично.

В кривых ООЯ, вроде C++ и Java, есть возможность сделать protected члены (как атрибуты, так и методы), что дает возможность использовать наследование реализации и, при этом, переиспользовать части базового класса.

Можно долго спорить хорошо это или нет, но в ряде ООЯ, которые давно считаются объектно-ориентированными, это есть. И это таки используется.

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

Ну и зачем после этого пытаться говорить, что в Rust-е поддерживается ООП?

Ну так многие и на C пишут, и дискомфорта не чувствуют.

сли для реализации некоторого трейта T нужен доступ к приватному полю S, то что?

Не надо ничего выносить, нужно реализовать трейт для нашего S:

impl T for S {
  fn foo(&self) -> {
    // Есть доступ к приватным, но только если мы владельцы S
  }
}

Боюсь, вы попутали SmallTalk с Self-ом и JavaScript-ом, емнип, в SmallTalk все нормально с классами, и со святой троицей.

Self и JS тоже неплохой аргумент, но я говорил именно о SmallTalk-е и его создателе (авторе ООП, Алан Кей), который не считает С++ ООП-языком, например.

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

Ты так говоришь, как будто protected это не «прощай инкапсуляция»

// Есть доступ к приватным, но только если мы владельцы S

Начинаю подозревать, почему доводы asaw-а не понимают.

Self и JS тоже неплохой аргумент, но я говорил именно о SmallTalk-е и его создателе (авторе ООП, Алан Кей), который не считает С++ ООП-языком, например.

Чтобы называть Алана Кея автором ООП, нужно, блин, совсем ничего не знать про Симула.

Еще и Джо Армстронг считает Erlang образцом ООП, давайте еще и это сюда приплетем.

Ты так говоришь, как будто protected это не «прощай инкапсуляция»

Вы явно путаете protected и friend.

Птица-секретарь

Выдержка ниже. Взято из Википедии.

Симула традиционно считается первым в мире объектно-ориентированным языком, но создатель языка Smalltalk Алан Кэй утверждает, что изобрёл термин «ООП»
Simula 67 явилась первым языком с встроенной поддержкой основных механизмов объектно-ориентированного программирования. Этот язык в значительной степени опередил своё время, современники (программисты 60-х годов) оказались не готовы воспринять ценности языка Simula 67

Нет, не путаю. И да, давайте не будем про friend, пусть о крестов будет хоть какой-то шанс.

Ну тогда расскажите, как же protected нарушает инкапсуляцию? Ведь если есть класс B, унаследованный от класса A, то экземпляр класса B отнюдь не перестает быть экземпляром класса A (не будем сейчас брать в расчет варианты с private-наследованием). Соответственно, атрибуты класса A остаются доступны только внутри класса A.

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

Иногда заявляется даже большее: наследование [реализаций] нарушает инкапсуляцию, хотя по факту имеют в виду именно защищённые поля:

— «Because inheritance exposes a subclass to details of its parent's implementation, it's often said that inheritance breaks encapsulation» (у Банды Четырёх)

— «Unlike method invocation, inheritance violates encapsulation [Snyder86]. In other words, a subclass depends on the implementation details of its superclass for its proper function.» у Д. Блоха.

— «But then closely related concepts should not be separated into different files [..] Indeed, this is one of the reasons that protected variables should be avoided.» у Б. Мартина в Clean Code.

— Ещё стоит поискать «inheritance breaks encapsulation» у Макконнелла.

Ну тогда расскажите, как же protected нарушает инкапсуляцию?

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

базовый класс недостаточно инкапсулирован от производных

Если под инкапсуляцией понимается объединение данных и кода их обрабатывающего, то данная фраза слишком заумна для моего понимания.

Пожалуй сольюсь и оставлю экспертов выдумывать про ООП новые небылицы.

Ведь если есть класс B, унаследованный от класса A, то экземпляр класса B отнюдь не перестает быть экземпляром класса A [...]

Только в том случае, если выполняется принцип подстановки Лисков, а для этого недостаточно написать class B: A.

Извините, но я слился. У меня не хватает мозгов, чтобы понять слова собеседников. Так, я не понимаю, каким боком принцип подстановки Лисков относится к нарушению инкапсуляции, например, в этом случае:

class MyIntVector {
  protected :
    int * begin_;
    int * end_;
    size_t capacity_;
  public :
    ... // Ни одного виртуального метода.
};
...
class MyIntVectorWithDebugPrint : public MyIntVector {
  public :
    void debug_print() const {
      std::cout << this << ": capacity=" << capacity_
        << ", begin=" << begin_ << ", end=" << end_
        << ", size=" << (end_ - begin_) << std::endl;
    }
};

Прошу прощения, но дальше без меня.

Логику же Rust-оманов в данном случае вообще понять не могу. Ну вот есть устоявшееся определение ООП. Ну не подходит Rust под это определение

Внезапно: средства поддержки ООП бывают разные. Про смоллтолк и джаваскрипт уже написали. Кстати, привет asaw'у с его неприятием добавления трейта к существующему классу, интересно, что он думает о js с возможностью менять поведение прямо в рантайме у конкретного экземпляра:D. Добавлю, что даже внутри «семьи» c++ наследование и инкапсуляция реализованы существенно по-разному. C++ позволяет множественное наследование интерфейсов, данных и поведения, притом есть 2 варианта наследования, простое и виртуальное. C# позволяет одиночное наследование данных и поведения, и множественное наследование интерфейсов. Java позволяет одиночное наследование данных и множественное наследование интерфейсов и поведения. Раст в этом плане недалеко ушёл, всего лишь запретили наследование данных. В плане инкапсуляции тоже по-разному, в c++ нагородили protected и friend, косящие под c++, Java и c# унаследовали всё, кроме френдов, вместо них добавив internal и «default», rust же решили ограничится закрытием реализации внутри модуля. Для впитавшего c++ с молоком матери это кажется святотатством, но если забыть на минуту заветы старика Страуструпа и попытаться подумать о практическом смысле, станет ясно, что все эти методы ограничения нужны только для того, чтоб указать, мол вот эту часть можете использовать, а вот эта часть - не ваше дело, могу менять как хочу и не гарантирую надёжную работу при неправильном обращении. В этом плане закрытие реализации внутри модуля как раз является естественным, одновременно есть доступ у кого надо и толко у кого надо. Можно смело менять потроха, не боясь поломать внешние зависимости (естественно, при условии неизменности интерфейса). Собственно вся эта пурга с private/protected/friend была добавлена в C++ не от хорошей жизни, а от отсутствия модулей и даже неймспейсов в момент зарождения языка. Раст не пытается играть в совместимость с C++ и умеет модули от рождения, логично что способ разграничения интерфейса и потрохов заменили на более пристойный.

Четкого определения ООП нет и труЪ реализации нет. Успокойся.

Внезапно: средства поддержки ООП бывают разные.

Внезапно: речь не про то, хорош ли подход Rust-а или плох, а про то, насколько правильно говорить о том, что Rust поддерживает ООП.

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

Добавлю, что даже внутри «семьи» c++ наследование и инкапсуляция реализованы существенно по-разному.

Вы еще добавьте, что это семья Симулы, а не C++. И что в мире статически-типизированных языков есть еще и Eiffel с нормальным множественным наследованием. А то ваш поток сознания не выглядит достаточно авторитетно.

ЗЫ. Менять поведение конкретного экземпляра в рант-тайме можно не только в JS, но и в SmallTalk/Ruby и, емнип, в Python-е. Это имеет большее отношение к динамической типизации, нежели к ООП.

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

В Golang нет наследования, но он успешен.

Если под инкапсуляцией понимается объединение данных и кода их обрабатывающего, то данная фраза слишком заумна для моего понимания.

Боюсь, это только в терминологии asaw понимается так буквально. Причём это не шибко-то работает даже для C++, так как данные-члены объявляются в .h файле, а работа с ними - в .cpp. В реальности инкапсуляция названа так из аналогии с другими областями, там под этим понимают изоляцию чего-то внутри другого чего-то, отсюда и общий корень с капсулой. Капсула - публичный интерфейс. Внутри - закрытая реализация. Наследование, как таковое, не всегда нарушает инкапсуляцию, но дело в том, что в практических случаях это происходит довольно часто. Поэтому и предлагают заменять наследование композицией, при композиции нет неявных зависимостей, делегация «предку» производится явно и только через его публичный интерфейс. Чисто для примера.

class List<T>:IList<T>
{
   public void insert(int index, T item){...}
   public void add(T item){...}
...
}

про то, насколько правильно говорить о том, что Rust поддерживает ООП.

Чего тут обсуждать? Поддерживает.

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

Ну вот вы сами и ответили. В C - вручную. А в расте не вручную. Вопрос можно закрывать.

Вы еще добавьте, что это семья Симулы, а не C++. И что в мире статически-типизированных языков есть еще и Eiffel с нормальным множественным наследованием. А то ваш поток сознания не выглядит достаточно авторитетно.

Пиписькомерство началось что ли? Ну да, я Симулу не знаю и знать не хочу. Есть что по факту возразить? Вот в C# я не могу наследоваться от 2х типов сразу, только через интерфейс и потому вынужден реализовывать методы второго предка сам заново, давайте рассказывайте мне про то, что в C# - это примерно как C с ручной реализацией ООП.

tailgunner

Нельзя сделать список элементов разных типов, но поддерживающих (реализующих) один интерфейс (трейт)

Можно.
По дефолту в расте предпочтителен статический полиморфизм, но для тем кому хочется странного динамического — есть Trait Objects.

fn main() {
    let number = 1;
    let string = "string".to_string();
    let vector = vec![1, 2, 3];

    let debug_vec : Vec<&Debug> = vec![&number, &string, &vector];   

    println!("{:?}", debug_vec);
}

stdout: [1, "string", [1, 2, 3]]

Это список указателей.

Если смотреть на сабж, он как был уныл и неюзабилен, так и остался.

Это список указателей.

Не спорю, а он хотел объекты разного размера в коллекцию пихать?

Я понял именно так. Поэтому и интересно, где такое возможно.

Учитывая вполне базовые знания Computer Architecture — это невозможно сделать эффективно в принципе, разве что на каких-нибудь связных списках со всеми вытекающими проблемами производительности.
Но это реализация конкретной коллекции и к языку в целом имеет мало отношения, ибо на коленке такое где угодно можно запилить.

В расте через енумы. Непонятно зачем, но возможно.

есть Trait Objects

Значит есть способ обойти обязательную мономорфизацию? Это, блин, дико правильно.

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

А можно пример такого использования енумов? Если это можно сделать без ансейфа, это мегакруто, хоть и абсолютно бесполезно :)

С точки зрения какого-нибудь smalltalk-а там и не ООП вообще, в отличие от современного догмата «ООП = классовая модель + троица».

«When I invented OOP, i wasn't mean C++» (c) Alan Key

В классическом смоллтоке (что становится ясно если почитать статьи Алана Кея, например ранняя история смоллтока) была реализована модель акторов Карла Хьюита + пару инсайтов Кея + реализация от Дэна Ингалса (который не знал CL и CLOS, например, а знал бейсик. и поэтому изобрёл что-то отличное от CLOS)

эта идея с 70х прослеживается в : SmallTalk, Self, JavaScript, Pony, Scheme.

Scheme вообще появился в конце тех же 70х как скрещивание лямдба-исчисления с моделью акторов (ну и уже позже 'let over lamda' Дага Хойта, как осмысление подхода)

да, там не «ООП = классовая модель + троица».

а, скорее «ООП = метаобъектная модель + динамическая диспетчеризация»

динамическая диспетчеризация позволяет реализовать прокси-объекты, протоколы и категории в Objective C (то есть, более reusable интерфейсы)

в объектной модели COS эта тема ещё более развёрнута: «мультидиспетчеризация и мультипараметризация»

вообще, надо различать ООП как идею, концепцию, метапарадигму :-)

и конкретную реализацию объектной модели (например, ООП как в Simula67/C++85, Beta : «ООП = классовая модель + троица» )

например, в CLOS/CL другая объектная модель. в смоллток — третья. в Eiffel — четвёртая (похожая на классическую троицу, но более reusable: reversibility/seamlessness, BON method, Eiffel method, Design By Contract, компиляторно-вычисляемый virtual, частично абстрактный/абстрагированный в потомках метод/свойство и наоборот(из абстрактного в конкретное), замена в потомках свойства на метод и наоборот, ковариантность/контравариантность, retry в исключениях, catcalls, SCOOP.)

Боюсь, это только в терминологии asaw понимается так буквально. Причём это не шибко-то работает даже для C++, так как данные-члены объявляются в .h файле, а работа с ними - в .cpp.

OMG. Да ты же не понимаешь о чем говоришь. Ты пишешь об отделении деталей реализации от определения типа и говоришь, что это плохо для инкапсуляции. Назови это абстрагированием. В любом случае как раз это-то работает на пользу инкапсуляции/абстрагированию. Ладно, я уже понял, что любители раста - так же любители поиграть в слова.

В Rust-е этого нет.

Потому что в Rustе это бессмысленно, т.к. нет наследования данных.

Ни одного виртуального метода

Так в исходном посте надо было сказать: B является А, если в А нет ни одного виртуального метода. В этом случае принцип подстановки выполняется автоматически, и наследование реализации ничем не отличается от наследования интерфейса и композиции.