Rust 1.12

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

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

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

Скажи честно: ты тоже под инкапсуляцией понимаешь «связь данных с методами», а не «сокрытие реализации»? Только чур без философии, просто да или нет.

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

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

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

Нет. Это ортогональные понятия.

Да. Не ортогональные.

Нет. Сходи по ссылке.

А вот в Java и его потомках, от множественного наследования отказались (ибо не смогли как в Eiffel), отсюда и пошло проникновение интерфейсов в мейнстрим.

Да какая разница, откуда они проникли в мейнстрим. Они были в языка с множественным наследованием (Си++), с одиночным (Objective C), и даже вектор операций в Си - тоже интерфейс.

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

Сокрытие реализации — это несколько другая тема.

Не менее необходимо доказать, что наследование интерфейсов — это есть то самое наследование из святой троицы ООП ;)

Вот на тебе определение сути ООП от человека, изобретшего само понятие ООП (обрати внимание, никакими троицами тут не пахнет):

http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented

I have asked Alan Kay about his definition of «object oriented» and he told me in 2003:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things.

Вот на тебе определение ООП из википедии (что характерно, тоже без троиц):

https://en.wikipedia.org/wiki/Object-oriented_programming

Object-oriented programming (OOP) is a programming paradigm based on the concept of «objects», which may contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods. A feature of objects is that an object's procedures can access and often modify the data fields of the object with which they are associated (objects have a notion of «this» or «self»). In OOP, computer programs are designed by making them out of objects that interact with one another.

Так что ваше увлечение троицами — это ваши личные, интимные проблемы. Жесткая связь между ООП и ортодоксальной «троицей» есть только в ваших субъективных преставляениях об ООП.

Лично для меня квинтессенция ООП — это принципы SOLID. И rust к ним вполне приспособлен.

Да какая разница, откуда они проникли в мейнстрим.

Разительная.

Они были в языка с множественным наследованием (Си++)

Даже если счесть нестандартное расширение одного из компиляторов за «были», то сам факт их исчезновения из языка с множественным наследованием говорит сам за себя: в языке с нормальным множественным наследованием отдельное понятие интерфейса является лишней (т.е. не нужной) сущностью.

Лично для меня квинтессенция ООП — это принципы SOLID.

Ну найдите упоминания о SOLID-е в процитированных вами определениях. Потом расскажите всем о собственных интимных проблемах.

Ну найдите упоминания о SOLID-е в процитированных вами определениях.

Так ведь я, в отличие от вас, не пытаюсь подменить solid-ом само определение ООП. Давайте уже по существу: Rust 1.12 (комментарий)

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

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

И снова непонятно слово «заморочка». Интерфейс — вполне естественное понятие, вытекающее из статической типизации. Для меня заморочка - это скорее отсутствие явных интерфейсов в динамических языках. И эмуляция интерфейсов на классах как в C++ - тоже заморочка, не вполне естественная.

Также непонятны отсылки ко множественному наследованию — вроде оно ни в каких определениях ООП не фигурирует.

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

Ну удачи, чо.

сам факт их исчезновения из языка с множественным наследованием говорит сам за себя:

Факт их исчезновения говорит о том, что идея отвергается, если ее время не пришло.

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

Как знать. Разговоры о runtime concepts - это неспроста.

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

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

Вот тебе ссылка и не мешай нам флеймитьне оффтопь здесь.

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

Не помню. Помню, как говорилось, что в Java решили не включать множественное наследование дабы избежать сложностей, которые были в C++ (ведь Java позиционировалась тогда как «правильно сделанный C++»). И это по официальной версии.

И снова непонятно слово «заморочка».

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

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

Но вот если мы смотрим на ООП в статически типизированных языках, то обнаруживаем вещи, которые происходят из этой самой статической типизации. В частности, интерфейсы. Т.е. для самого ООП «вообще» отдельно оформленное понятие «интерфейса» как языковой сущности не нужно. Но в некоторых статически типизированных ООЯ — нужно, отсюда и «заморочка».

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

и не мешай нам флемит

Вот ещё! Надо больше неразберихи в треде.

Как знать. Разговоры о runtime concepts - это неспроста.

Как по мне, так это не имеет отношения к ООП.

C++ ведь никогда не был чистым ООЯ (в отличии от Eiffel-я и Java). В свое время он вбирал идеи из функциональщины (емнип, шаблоны в C++ — это заимствование из ML и Ada), и продолжает это делать. В эту же сторону и концепты.

Это вы троллите или реально не понимаете?

Реально не понимаю. Вот C - язык со статической типизацией. И без динамической диспетчеризации. И живёт. Раст, если бы в нём не было trait object'ов тоже был бы языком со статической типизацией и без динамической диспетчеризации. Трейты использовались бы только для ограничения дженериков. С другой стороны можно представить язык с динамической типизацией, в котором при компиляции методы всех классов собираются в один список и для каждого фактического класса создаётся виртуальная таблица, в которой просто чужие методы забиты заглушками.

Rust выглядит как язык, который предлагает несколько другие инструменты для борьбы со сложностью. В частности это абстрактные типы данных, алгебраические типы данных, обобщенное программирование. Очень нехилый набор инструментов. Особенно если сравнивать с C или Go.

Безусловно так и есть. Если вы под ОО языком понимаете язык, зацикленный на ОО парадигме, то да, Rust к таким не относится. Но поддержка ОО, тем не менее, в язык интегрирована.

И вот не понятно, зачем утверждать «Раст просто по факту язык, поддерживающий ОО»?

Потому что есть в нём инструменты для ОО. Вот сравнить с C#, в нём наследование данных и методов ограничено 1 предком, а в Rust'е данные ограничены 0, зато методы можно наследовать от неограниченного количества предков. Вот я почему-то уверен, что 20 лет назад C++ программисты, с опытом работы над старым проектом (без RTTI), когда читали книгу «java за 21 день» точно так же говорили, что java - не полноценный ОО язык, так как предок всего 1, а instanceof - это корявка для слабаков.

Типа, это не говно, я не зря на него перешел?

Тут, по-моему, только asaw считает, что поддержка ООП - это то, без чего язык неполноценен.

Разговоры о runtime concepts - это неспроста.

Как по мне, так это не имеет отношения к ООП.

Cами интерфейсы - это не ООП, поэтому выражение интерфейсов с помощью ООП (наследования в Си++) неестественно. Но у трейтов конкретно Rust есть операция наследования, и вот это уже можно (при желании) считать ООП.

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

Это противоречит самой природе динамической типизации.

Если вы под ОО языком понимаете язык, зацикленный на ОО парадигме, то да, Rust к таким не относится.

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

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

Тут, по-моему, только asaw считает, что поддержка ООП - это то, без чего язык неполноценен.

Безотносительно того, прав ли asaw или нет, я лично не понимаю, почему растоманы так рьяно бросились доказывать, что Rust — это ООЯ. В Rust-е свой набор инструментов, как и, скажем, в Haskell-е. Возможно, в каких-то классах задач инструментарий Rust-а гораздо удобнее, чем таковой в Java или C#, или в C++.

Cами интерфейсы - это не ООП, поэтому выражение интерфейсов с помощью ООП (наследования в Си++) неестественно.

Можно и так сказать. Как по мне, так интерфейсы — это инструмент для поддержки абстрактных типов данных.

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

Тем не менее, АТД и ООП — это разные вещи. Поэтому, на мой взгляд, Rust — это язык с АТД (и АлгТД в придачу), но вот ООП в нем в чистом виде нет.

я тут со всеми на ты общаюсь (в обе стороны)

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

если интересно именно это обсудить — то инкапсуляция это только один из способов обеспечить соблюдение инварианта

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

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

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

вообще речь у нас о терминах, и там могут быть разные мнения — вон википедия пишет, что не все разделяют деление на инкапсуляцию и information hiding

но мой пойнт в том, что инварианты нужны железно (в смысле обязательно), а вот information hiding может быть под вопросом

скажем, если мы проектируем тип Time с обычными операциями Time::get_year(), Time::set_year(int), ... Time::get_second(), Time::set_second(int), то можно и позволить например time.set_second(100500), которая будет переводить секунды в минуты, часы и т.п. и добавлять их тоже, а не только ставить секунды (примерно как в ui андроида)

но обязательно get_second() после этого не должна возвращать 100500 — это будет нарушением инварианта

а теперь information hiding — нужно ли предоставлять get_seconds_since_epoch(), где эпоха не юниксовая, а некая своя? можно *спорить* на тему, что этот метод выдает наружу деталь реализации — именно спорить

еще пример: пусть нам нужен класс Point { float x; float y;} про который известно, что x и y имеют точность существенно ниже аппаратного float

и как ты будешь скрывать деталь реализации — а именно, последние мусорные биты float-а? скорее всего, никак

да, можно наколбасить на шаблонах imprecise_float, но у него *все* операции будут ровно те же, что и у обычного float-а, и смысл его будет только в том, чтобы где-то компилятор ругнулся на его конверсию в обычный float; вряд ли этот imprecise_float действительно будет полезным при разработке софта

Поэтому, на мой взгляд, Rust — это язык с АТД (и АлгТД в придачу), но вот ООП в нем в чистом виде нет.

Если чистым видом считать Java и Си++, с наследованием реализации - его нет. Но, с другой стороны, что мы теряем? Ну да, бывает удобно конструировать типы наследованием. Вопрос только в том, достаточно ли это часто - если нет, то приведенный выше трюк с перегрузкой Deref вполне жизнеспособен.

Проблема в том, что вы вполне здравую и актуальную на сегодняшний день идею ООП пытаетесь подменить бестолковой троицей. На каком-то этапе развития (20-30 лет назад, да) действительно казалось, что троица удачно детализирует само понятие ооп. С тех пор было собрано немало опыта, сделано выводов, и на сегодняшний день место троицы — где-то на обочине той дороги, по которой движется ооп. http://programmers.stackexchange.com/questions/253090/why-are-inheritance-enc...

Не помню

http://www.artima.com/intv/gosling34.html

Размышления пост-фактум, но они показывают что даже одиночное наследование не считалось необходимым.

Поясню

Мысль понял, но посмотри на это с другой стороны: если стоит выбор между множественным наследованием и интерфейсами, то что замороченнее, причем и для разработчиков языка, и для его пользователей?

Множественное наследование потенциально мощнее, но эта мощь нужна слишком редко, чтобы так всё усложнять (сужу по C++), и проще будет написать чуть больше кода. История ЯП эту мысль подтверждает (а отдельно интересна тенденция вообще отказываться от наследования в новых языках).

Если чистым видом считать Java и Си++, с наследованием реализации - его нет.

О том и речь. Безотносительно того, хорошо это или плохо.

Но, с другой стороны, что мы теряем?

Это уже совсем другой вопрос.

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

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

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

А троица как описывала ООП, так и продолжает описывать.

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

Системный ЯП? А операционка на нём есть?

Да.

А троица как описывала ООП, так и продолжает описывать.

Троица описывает устаревший, имеющий серьезные изъяны, взгляд на ооп. ООП — это про локализацию и сокрытие state внутри объектов, про позднее связывание и про обмен сообщениями. Если опуститься до реализации, то чаще всего state заключен в аттрибутах объектов, позднее связывание достигается за счет того что объекты друг о друге мыслят в терминах абстракций (*контрактов*, и их бедных родственников - интерфейсов, трейтов, концептов), а обмен сообщениями осуществляется путем вызова стоящих за абстракциями конкретных связанных с конкретными данными процедур. Вполне возможны какие-то другие реализации, и это всё ещё будет ооп. А «троица» здесь попросту не релевантна.

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

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

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

Прекрасно. Давайте считать C объектно-ориентированным языком.

Он ещё и слабо типизированный при желании.

я чуть сократил (ненужные изменения имени) и добавил печать и профессию рабочему https://play.rust-lang.org/?gist=292bdef40f50f8016d34f21088312d97&version...

то приведенный выше трюк с перегрузкой Deref вполне жизнеспособен.

хм? возможно после сильной доработки, т.к. перегрузка Deref всегда возвращает указатель на Human-а

как сделать так, чтобы у обоих — и Human, и Worker была функция say, и у человека она печатала

println!(«I am {}», human.name );

а у рабочего че-то типа

println!(«I am {} and I am {}», human.name, profession );

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

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

Давайте считать C объектно-ориентированным языком.

На Си можно писать в объектом стиле (и GObject тому свидетель), но чтобы при этом считать сам Си объектно-ориентированным, не хватает сахара. Если сахар добавить, то получится очередной оо-язык с си-подобным синтаксисом. И что?

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

тебе тот же вопрос Rust 1.12 (комментарий)

как это сделать правильно?

может реализовать struct и trait OOPObject с таблицей виртуальных функций, плюс макрос(ы) для автоматической регистрации функции в этой таблице?

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

но чтобы при этом считать сам Си объектно-ориентированным, не хватает сахара.

сахар это не столь важно — сахар можно добавить внешним глупым препроцессором (даже на регекспах)

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

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

UPD: в 43 строке благодаря Deref можно просто писать self.name :)

Ой, ну ладно. А что скажешь про это?

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

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

receive
  {foo, A} ->
    foo(A);
  bar ->
    bar(A),
    ok
end

В то время как вызов методов диспатчит рантайм языка (ну или компилятор генерирует код для этого прямо на месте, как в С++).

Системный ЯП? А операционка на нём есть?

Несколько.

Воспроизведи на play.rust-lang.org

Лицензия не позволяет :)

ССЗБ

Ясно :D

Скажу что ты собираешь не программу а библиотеку.

cargo new --bin azaza

http://imgur.com/YeJOIIi