Rust 1.12

Ну а как ещё если ты не понимаешь, что ООП и есть метод декомпозиции?

А какое там основное правило структурной парадигмы?

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

Да-да, придумали огромный костыль: https://github.com/rust-lang/rfcs/pull/1023 А всё потому, что инкапсуляции данных нет.

А какое там основное правило структурной парадигмы?

Стркутурная парадигма - это структурная парадигма, а ООП - это ООП. Это разные подходы.

Так а интерфейс то у А какой? Чтобы это понять я должен пройтись по всем его impl не так ли?

Достаточно посмотреть impl A {..}, во всех остальных случаях интересовать должно не «а какой интерфейс у A», а «реализует ли A такой-то интерфейс», а где это искать зависит от того какой типаж. Если твой, то у тебя, если не твой, то в библиотеке, которая предоставляет A.

Соб-но, так документация и строится: https://docs.rs/, выбирай любой для примера.

Причём тут инкапсуляция-то?

Специализация решает конкретный кейс: есть очень общее определение, скажем «реализовать ToString для всего, что реализует Display простым вызовом display()», а ты хочешь переопределить это своего конкретного типа этот самый ToString (в целях оптимизации).

В крестах этот обобщённый «ToString для Display» в принципе невозможно сделать (костыль через множественное наследование 100500 «классов» мы не рассматриваем). Вот и профукалось ваше ООП.

Дык, а кто тут утверждает что ООП и есть декомпозиция?

Достаточно посмотреть impl A {..}, во всех остальных случаях интересовать должно не «а какой интерфейс у A», а «реализует ли A такой-то интерфейс», а где это искать зависит от того какой типаж. Если твой, то у тебя, если не твой, то в библиотеке, которая предоставляет A.

Вот и получается, что в Расте ты думаешь не в терминах интерфейса объекта, а в терминах реализации. Потому что объект и его поведение (интерфейс) изначально никак не связяны. Связываются они только реализациями. Причем, множество этих реализаций практически никак не ограничивается (за исключением упомянутого выше костыля).

Причём тут инкапсуляция-то?

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

В крестах этот обобщённый «ToString для Display» в принципе невозможно сделать (костыль через множественное наследование 100500 «классов» мы не рассматриваем). Вот и профукалось ваше ООП.

Ну да, если выкинуть из языка именно ту фичу, с помощью которой это и реализуется (предварительно высказав про неё своё субъективное мнение и обозвав костылём), то можно сказать, что невозможно (хотя там ещё CRTP остаётся для реализации концепций типа mix-in). А так ещё Скотт Майерс 15 лет назад описывал как такие вещи делать.

Дык, а кто тут утверждает что ООП и есть декомпозиция?

ООП - один метод декомпозиции. Структурная парадигма - другой.

[quota] Почему тебе не посмотреть реализацию stdlib? https://doc.rust-lang.org/std/net/ [/quota]

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

trait BaseSocket {
   fn get_fd(&self) -> i32;
   fn close(&mut self) {
      do_sys_call_socket_close( self.get_fd() );
   }
}

pub struct UDPSocket {fd:i32};
impl UDPScoket {
  fn send_to(&mut self, &addr) {
    ......
  }
}

impl BaseSocket for UDPSocket {
   fn get_fd(&self) -> i32 { self.fd }
}

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

Но както выглядит не очень

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

То, что ты об интерфейсе узнаешь не из строчки class A : public B, а из строчек impl Foo for A абсолютно ничего не меняет.

А можно мне твоё видение impl<T> ToString for T where T: Display + ?Sized в Ъ-ООП стиле?

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

В смысле ? Я чтото не так понял или в том плане что свои сокеты велосипедить никому не нужно ?

(предварительно высказав про неё своё субъективное мнение и обозвав костылём)

(за исключением упомянутого выше костыля)

Какие двойные стандарты.

Ненужная - значит, что ты пытаешься абстрагировать какие-то ненужные вещи. Если делаешь библиотеку сокетов, то хотя бы не занимайся банальщиной вроде «абстракции read/write/close», а попытайся абстрагировать что-то полезное вроже «байтовый поток vs дискретные сообщения» (как сделано в Rust).

Я не делаю библиотеку сокетов. Я пытаюсь расмотреть конкретную проблему на конкретном примере. А именно общую кодовую базу при реализации двух различных сущностей не более того ...

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

Вообще-то классическое определение - это изоляция внутренней реализации от интерфейса, и сокрытие подробностей реализации. Ну ОК, давайте возьмём ваше определение. Итак, в чем отличие крестового класса от растовой структуры? Не касаясь различия в АБИ, и там и там есть данные и методы. На первый взгляд, различие в том, что в цпп в объявлении класса перечислены также методы, что, конечно, никак не обеспечивает более плотную связь, но, по идее, делает поиск интерфейса класса чуть проще. Но только на первый взгляд: и IDE (даже те, что есть сейчас), и автоматически сгенерированная документация в расте отлично покажет и трейты и методы структуры, с другой стороны из-за наследования в объявлении крестового класса объявлены не все методы и данные, а из-за необходимости объявлять также и приватные методы и дружественные функции и классы, объявление класса настолько захламлено, что никакой особой ясности там нет. В итоге и там и там «связь» класса и методов находится либо через подсказку IDE, либо через документацию. С другой стороны, реализация интерфейсов «сбоку» имеет свои плюсы именно с точки зрения ООП. Согласно принципам ОО дизайна, клиентский код должен зависеть от абстрактного интерфейса, а не конкретных реализаций. Что означает необходимость включения в интерфейс всех частей алгоритма, которые могут варьировать я от реализации к реализации. С другой стороны эти же принципы требуют не перегружать интерфейс, да и не факт, что интерфейс и конкретные классы доступны для модификации. Чтоб решить этот конфликт, нужно городить копию дерева типов из адаптеров. В расте адаптеры не потребуются, просто свой трейт и реализации для конкретных типов.

То, что ты об интерфейсе узнаешь не из строчки class A : public B, а из строчек impl Foo for A абсолютно ничего не меняет.

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

А можно мне твоё видение impl<T> ToString for T where T: Display + ?Sized в Ъ-ООП стиле?

Если тебе нужна не-ООП фича, то тебя никто не заставляет использовать ООП, можешь просто использовать обобщенные функции со специализациями/частичными специализациями - C++ это может, если ты про это. Если, всё же, хочется именно ООП, то есть известный паттерн на эту тему: https://en.wikipedia.org/wiki/Visitor_pattern

Уже обсуждали выше с примерами. Не буду тебе снова всё пересказывать.

Да хоть сто вложенных модулей. Мне ничего не помешает, например, приделать к этому же самом объекту новое поведение в другом месте. То есть все думали, что объект типа «улитка» умеет только ползать, а она вдруг раз - и полетела, потому что какой-то шутник прилепил к ней трейт Wings. С другой стороны, поскольку инкапсуляции нет, то нет и наследования поведения когда это нужно. Потому что невозможно сделать наследование сферического поведения в вакууме. Поведение в общем случае связано с состоянием, то есть с данными.

Во-первых, в тех же c++ такое тоже возможно. class Mysnall: public Snall, public Wings { и привет, код, который не создаёт объект сам (а с фабриками никто не создаёт объект сам) не может быть уверенным в свойствах. Более того, даже интерфейс Wings не нужен, просто наследовался и переопределил какой-нибудь CanFly и привет. В этом как раз и проблема наследования реализаций. Во-вторых, в расте навешивание трейтов ограничено. Навесить можно любой трейт на свой тип, либо свой трейт на любой тип. Если тип улитка или трейт крылья определены тобой, тебе лучше знать, умеет ли улитка летать. Если кому-то нужно отправить улитку на другой конец Земли, он может реализовать для неё свой трейт FlyByPlane, реализовать посадку улитки в самолёт посредством её стандартных движений.

Вообще-то, похоже, никто так и не понял, что ты пытаешься растолковать. «тут инкапсуляция есть, а тут нет, потому что я так сказал».

Во-первых, в тех же c++ такое тоже возможно. class Mysnall: public Snall, public Wings {

Нет, тут смысл в том, что в C++ ты для этого создаешь НОВЫЙ ТИП, а в расте ты можешь волшебным образом добавить новое поведение старому.

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

Ровно таким же способом можно добавить новое поведение и в Си++ .

class Flyable {
  Snail *snail_;
public:
   void fly() { snail_->crawl(); }
}

С каких это пор добавление нового поведения нарушает инкапсуляцию данных? Может ты еще скажешь что в C# нет инкапсуляции, потому что там есть extension методы?

Нет, тут смысл в том, что в C++ ты для этого создаешь НОВЫЙ ТИП, а в расте ты можешь волшебным образом добавить новое поведение старому.

Как я уже писал, в мире IOC и фабрик ты не работаешь с типами, ты работаешь с объектами этого или наследуемого типа, которые, весьма вероятно, создаёшь не сам. Ну вот у меня есть код

void PetCollection::AdoptPet(Snail*newPet)
{
    m_Fence.Add(newPet); // помещаем за оградку, так как не умеет прыгать или летать
}

Вашему терпению можно позавидовать. Вы столько времени пытаетесь донести до Rust-оманов простые и очевидные вещи, но все как горохом о стену.

Логику же Rust-оманов в данном случае вообще понять не могу. Ну вот есть устоявшееся определение ООП. Ну не подходит Rust под это определение. Но зачем-то Rust-оманам нужно натягивать сову на глобус. Ведь можно же просто сказать — этот ваш ООП отстой в принципе, поэтому в Rust-е сделали следующий шажок в эволюции и решают эти же проблемы другими средствами. И эти средства типа лучше, чем классический ООП.

Но вместо этого начинается — ООП кривой, наследование реализации — кривизна, ООП в C++/C#/Java — кривое и т.д., и т.п. А вот в Rust-е ООП — такое как надо ООП. Настоящее.

LoL
«Кукушка хвалит петуха»

Вашему терпению можно позавидовать.

Вы не понимаете. Человек мир спасает. Ради такой цели сутками на форуме сидеть - тьфу. Ведь если не прибить процедуры к данным гвоздями, то что угодно может случиться.

Только представьте: кто-то может реализовать метод reproduce(e: Environment) для структуры Virus, хотя это структура не унаследована от структуры Animal. Ужасно. Если человек на такое решился, то у него уже нет никаких моральных ограничений. Я даже не хочу думать, что он там может понаписать. /s

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

Последний раз тебе повторяю: перестань смотреть на синтаксис и смотри на семантику. Если хочешь иметь инкапсуляцию в твоём понимании, то объявляешь реализацию рядом с данными. Если хочешь гибкости, то используешь возможности языка, а не непонятные надуманные ограничения.

Интереснее то, что наследование конфликтует с твоим определением инкапсуляции, потому что поведение задаётся не здесь, а в базовом классе.

Действительно, не понимаю. ООП — это устоявшаяся за 30+ лет троица: инкапсуляция, наследование, полиморфизм. Если это все в языке X из коробки — значит язык X можно назвать ООЯ. Нет — значит нельзя.

Не более того.

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

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

Новое поведение на основе его публичного интерфейса и только если типаж твой. Пример с улиткой от khrundel очень показателен, перечитал бы ты его ещё разок.

ты для этого создаешь НОВЫЙ ТИП

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

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

Реализация - это то, что в фигурных скобочках. А интерфейс - это название функции и её сигнатура (та штука, которую в C/C++ копипастят в/из заголовочные(х) файлы(ов)). В Расте, созданием человекочитаемой документации на интерфейс занимается генератор документации.

Эй нет, вряд ли здесь какой-то rustоман будет утверждать, что там есть ООП (как минимум потому что под ООП сегодня понимается всё что угодно, поэтому и говорить об этом смысла чуть более, чем нисколько). Но тут приходит человек и начинает оперировать отдельными понятиями (считая их каким-то особым свойством его недоязычков), которые, как внезапно выясняется, выполняются и в rust-е.

Это просто значит, что язык не ООЯ.

Спор в основном идет не о классификации Раста. asaw утверждает, что язык без наследования реализаций - не язык, а ходячее недоразумение, или что-то в этом роде.

А зачем так сложно, когда есть free functions?

Мне показалось, что речь о другом. asaw говорит, что если в языке нет инкапсуляции и наследования (реализаций), то язык не поддерживает ООП, а это не есть хорошо, т.к. ООП уже доказало свою состоятельность и т.д. и т.п.

На что ему говорят, что в С++/C#/Java — кривое ООП, а вот в Rust-е то с ООП все нормально как раз из-за того, что в языке нет ни инкапсуляции, ни наследования реализации.

Безотносительно того, прав ли asaw в том, что ООП нужно, аргументы против точки зрения asaw-а выглядят довольно странно. Причем формально-то asaw прав: нет соответствия святой троице ООП — нет и ООП в языке.

Нет, не скажу. Там есть инкапсуляция и есть extension методы. Или как в C++ - есть инкапсуляция, и есть free functions. А вот в Си инкапсуляции нет, есть только free functions, хотя даже вполне можно привязывать функции к объектам.

Добавление трейта ничем не отличается от добавления extension метода. И раз второе не нарушает инкапсуляцию по твоему мнению, значит и первое не должно.

Последний раз тебе повторяю: перестань смотреть на синтаксис и смотри на семантику. Если хочешь иметь инкапсуляцию в твоём понимании, то объявляешь реализацию рядом с данными. Если хочешь гибкости, то используешь возможности языка, а не непонятные надуманные ограничения.

Так в этом то и предмет обсуждения: что непосредственно позволяет выразить язык. В Си тоже можно «не смотреть на синтаксис, а смотреть на семантику», и видеть там ООП, только это не означает, что в Си есть поддержка ООП.

Интереснее то, что наследование конфликтует с твоим определением инкапсуляции, потому что поведение задаётся не здесь, а в базовом классе.

Я здесь никаких своих определений не приводил, только общепринятые.

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

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

Недавно как раз был соответствующий наброс: Why I’m dropping Rust. IIRC, человек там как раз жаловался на отсутствие наследования реализации.

Понятное дело, что православные Rust-оманы уже предали автора сего опуса обструкции :)

Добавление трейта ничем не отличается от добавления extension метода. И раз второе не нарушает инкапсуляцию по твоему мнению, значит и первое не должно.

Как можно нарушить что-то, если его и так нет?)

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

Правильно. Раст позволяет выразить то, что ты подразумеваешь под инкапсуляцией. То, что для этого используются другие ключевые слова суди дела не меняет. А стоит ли так писать код, когда язык предоставляет лучшие концепции это второй вопрос.

Причем формально-то asaw прав: нет соответствия святой троице ООП — нет и ООП в языке.

Инкапсуляция есть, что бы asaw не думал.

mod M {
    pub struct S {private_field: u32}
    impl S { pub public_interface(&self) {} }
}

Доступ к внутренностям S возможен только с помощью публичного интерфейса.

Открытой рекурсии нет (https://en.wikipedia.org/wiki/This_(computer_programming)#Open_recursion). Это верно. Впрочем, о проблемах открытой рекурсии известно давно (см. ссылки на литературу в википедии). Поэтому, кстати, и можно говорить о «кривизне С++/С#/Java».

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

Да и вообще, ООП это такое размытое понятие, что спорить об определениях особого смысла нет. В статье из википедии, куча ссылок на литературу, где пытаются систематизировать, что же всё-таки такое ООП. Формального определения, насколько я знаю, нет.

На что ему говорят, что в С++/C#/Java — кривое ООП, а вот в Rust-е то с ООП все нормально как раз из-за того, что в языке нет ни инкапсуляции, ни наследования реализации.

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

Ну а кривое ООП или не кривое в С++/С#/Java это сложный вопрос. С точки зрения какого-нибудь smalltalk-а там и не ООП вообще, в отличие от современного догмата «ООП = классовая модель + троица».

То есть по существу ответить нечего?

Как можно нарушить что-то, если его и так нет?

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

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

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

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

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

Отсутствие языковых средств для выражения состояния и поведения типа как единой сущности.

А зачем так сложно, когда есть free functions?

А причем здесь free functions, если речь о трейте?