Rust 1.12

В наследовании интерфейсов. В динамически-типизрованных языках этих заморочек нет. Ваш К.О.

Так себе К.О. Скажем, в Racket интерфейсы есть, наследование интерфейсов тоже, а язык-то динамически типизированный.

Как, например, наличие лямбд не делает C++, Java и C# функциональными языками.

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

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

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

Ты тут на каждый мой комментарий будешь высказывать своё неповторимое особое мнение?

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

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

Ну то есть, возражений нет? И в С++ точно так же можно размазать реализацию, только оно ещё и может внезапно выстрелить благодаря ADL.

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

Хорошо, тогда разве этого в расте нет?

Если что, мне совершенно не интересно доказывать «полноценность ООП» в расте. А вот с отсутствием инкапсуляции категорически не согласен.

Кстати, не отрицаю, что в С++ всяких «связанных с ООП штук» больше - это очевидно. Другое дело, что отношение к вещам типа protected и friend неоднозначное. Да, оно бывает весьма удобно, но не факт, что в языке с наличием других механизмом оно необходимо. Тут я пока не определился.

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

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

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

Хорошо, тогда разве этого в расте нет?

Об этом уже говорилось. Интересная фишка Rust-а в том, что у нас может быть некая структура S и некий трейт T, которые появились независимо друг от друга. И если какому-нибудь Васе Пупкину потребуется использовать экземпляры S там, где ожидается T, то Вася Пупкин может реализовать T для S. Не спрашивая разрешения у авторов S и T.

Это интересная фича.

Но, имхо, пользу она приносит тогда, когда содержимое S открыто. Тогда Вася Пупкин не имеет препятствий для реализации T.

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

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

DarkEld3r, eao197 Да это же адекваты в треде. Слава ктулху, наконец-то.

И если какому-нибудь Васе Пупкину потребуется использовать экземпляры S там, где ожидается T, то Вася Пупкин может реализовать T для S. Не спрашивая разрешения у авторов S и T.

Не получится. Раст позволяет имплементить любой интерфейс для типа из текущего модуля, либо интерфейс из текущего модуля для любого типа.

Не получится. Раст позволяет имплементить любой интерфейс для типа из текущего модуля, либо интерфейс из текущего модуля для любого типа.

Хм... похоже, прежде чем на раст можно будет посмотреть я на пенсию уйду.

protected - это скорее способ инкапсуляцию нарушить

Ага, есть такое дело.

Ну то есть, возражений нет? И в С++ точно так же можно размазать реализацию, только оно ещё и может внезапно выстрелить благодаря ADL.

В C++ точно так же «размазать» ничего нельзя, потому что поведение определяется в интерфейсе, который ты наследованием не поменяешь. Вы, растаманы, просто органически не отличаете интерфейс от реализации. Кроме того, наследованием ты создаёшь новый тип, что тоже легко отслеживается при желании.

А это вот не способ?

https://is.gd/bmBJwr

Какие обширные обоснованные выкладки касательно психологии незнакомых людей. Гаданием по картам занимаешься в перерывах между go и ocaml?

Мальчик, я жизнь прожил, видел таких.

Или работать на крупные компании за деньги достаточные, чтобы не клянчить подачек на зимнюю резину за баги — не достаточно по-хипстерски?

За 200 баксов? Месяц работать? Да ты ебанцтый.

Композиция жеж, мимикрирующая под наследование. Причём тут инкапсуляция и protected-члены?

no comment...

Что «no comment»?
Ты пальцем показать можешь в каком там месте protected-член и доступ к нему?

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

В С#, Vala, Java есть. В С++ вроде нету, там абстрактными классами выкручиваются.

Хочется что-то типа:

interface B {void f();}
class A1: B {}
class A2: B {}

B ar=new Array<B>();
A1 a11=new A1();
A2 a22=new A2();
ar.insert(a11 as B);
ar.insert(a22 as B);

foreach(a in ar){a.f();}

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

Ну это всё-таки уродство и, как по мне, справедливо считается антипаттерном.

Прошу немного, долларов 200, резину надо менять, винтер из каминг)

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

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

Зато более важный на практике.

Хочется что-то типа

Руст - системный язык, там неявной ссылочной семантики нет и не будет.

А у тебя есть full-time вакансии под rust? Город какой?

С полгода назад видел вакансию: full-time с возможностью удалённой работы (вроде). Украина/Киев. Искать лень, но могу попробовать, если на слово не поверишь.

так может, контролировать надо не в предке (поставщике интерфейса), а в потомке (потребителе) ?

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

Исключения можно найти из любого правила.

Вот только, вопреки популярному заблуждению, это не подтверждает правило.

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

Это всё-таки функциональность из коробки, а не сторонняя либа. Ну и возможность «создать какого угодно уродца», как по мне, является плюсом.

Вот только, вопреки популярному заблуждению, это не подтверждает правило.

SmallTalk, Ruby, Python, Self, JavaScript — нет такой языковой сущности, как интерфейс. Это не правило, это случайность. Я понял.

Вася Пупкин может реализовать T для S. Не спрашивая разрешения у авторов S и T.

Напрямую это сделать нельзя, но да, ограничение можно обойти.

Вот только разве в С++ не точно так же? Можно наследоваться от чужого интерфейса (а трейт - это, в принципе, интерфейс) и одновременно от чужого типа (ну или заменить агрегацией) и подсунуть эту обёртку. Тоже не спрашивая авторов.

Но, имхо, пользу она приносит тогда, когда содержимое S открыто. Тогда Вася Пупкин не имеет препятствий для реализации T.

Не обязательно. Васе может хватить публичного интерфейса S.

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

Вот мне и интересно услышать в чём именно оно проявляется. Отсутствие frient, protected - понятно. «Необходимость» использовать модули, а не классы для сокрытия, как по мне, принципиально ничего не меняет. Что-нибудь ещё?

Хм... похоже, прежде чем на раст можно будет посмотреть я на пенсию уйду.

Почему? Тебе кажется, что это слишком сильное ограничение?

Вот только если обращаться к аналогиям, то всё нормально. Возьмём плюсы: в либе A есть интерфейс I, в либе B тип T. Нельзя взять и реализовать интерфейс именно для этого типа (не трогая исходники). Зато можно сделать обёртку:

class W : public A::I, public B::T {
    ...
}

В C++ точно так же «размазать» ничего нельзя, потому что поведение определяется в интерфейсе

Ну давай в терминах плюсов. Есть интерфейс Crawler и класс Snail, который от него наследуется. Дальше я делаю FlyingSnail и в реализации метода crawl лечу. Ну прямо как ты показываешь в соседнем примере кода.

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

Вы, растаманы, просто органически не отличаете интерфейс от реализации.

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

Хочется что-то типа:

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

Вот только разве в С++ не точно так же?

Если S — это struct, а T — это абстрактный класс, то можно. Только вот в общем случае в C++ S не будет структурой. И наружу не будут торчать детали, необходимые для реализации T.

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

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

но могу попробовать, если на слово не поверишь

Не трать время. Тем более, что на фоне всей этой нацпольной истерии мне украина никаким боком не актуальна. За инфу спасибо

SmallTalk, Ruby, Python, Self, JavaScript — нет такой языковой сущности, как интерфейс. Это не правило, это случайность. Я понял.

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

В Pharo (реализация Smalltalk) есть трейты, которые представляют собой как раз интерфейсы.

В Ruby, вроде, совсем ничего такого нет, да. Хотя есть статьи и рукопашные реализации. Даже интересно зачем на это идут программисты на вполне приличном языке, таким же только извращенцы-лисперы должны заниматься?..

В Python есть абстрактные базовые классы и, опять же, наколеночные реализации. Если что, про их популярность ничего говорить не собираюсь.

В JavaScript interface, вроде, является зарезервированным ключевым словом? Может когда-нибудь что-то и добавят на эту тему. (:

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

И наружу не будут торчать детали, необходимые для реализации T.

Дык, и в расте в общем случае потроха S наружу торчать не будут. В смысле, я не вижу разницы. Мы случайно не о разных вещах говорим?

Ну не меняет, ну что тут поделать.

Просто из любопытства: а если взять привычный С++ и заменить public/private на какие-нибудь другие ключевые слова инкапсуляция станет «своеобразной»? А если запретить группировать данные/методы и требовать указания перед каждым? Или пусть доступность зависит от кейса первой буквы поля/функции. Или же сделать так, чтобы это перед классом перечислялось, как-то так:

class C [public: a, b, c, private: d, e] { ... }

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

Очевидно, что некий API, за который можно дергать объекты, является интерфейсом. И интерфейс, как логическое понятие, архиважен, т.к. без интерфейса не понятно, как выражать этот самый API.

Однако, речь идет не о понятии, а об отдельной языковой сущности. Надобность в которой есть в статически-типизированных языках (ибо в компайл-тайме нужно проверять допустимость вызова). А вот для динамических, как показывает обширный опыт, — нет. По большому счету duck typing как раз и базируется на том, что нет этих самых интерфейсов как языковых сущностей.

Дык, и в расте в общем случае потроха S наружу торчать не будут. В смысле, я не вижу разницы. Мы случайно не о разных вещах говорим?

Видимо, ваше знание Rust-а намного лучше моего. Я, например, полагал, что если в модуле m1 есть структура S, а в модуле m2 — трейт T, то Вася Пупкин в модуле m3 может сделать свою имплементацию T для S.

Мне казалось, что это очень интересная фича. Возможно, одна из killer features языка.

Но, как мне тут указали, я не прав. Вася Пупкин может сделать имплементацию T только в модуле m2. Что, имхо, превращает эту воображаемую фичу в пшик. Но Rust-оманам нравится, так что пусть балуются.

В общем, где грань проходит? (:

У устоявшихся привычках. Как-то так повелось, что в ООЯ единицей инкапсуляции является класс (или объект, если уж речь про прототипные ООЯ). Исключения, конечно же, можно найти. В частности в Java есть package visibitility. Но, в тех ООЯ, с которыми доводилось работать, все-таки инкапсуляция замыкалась на класс/объект. И к этому привыкаешь.

Но Rust-оманам нравится, так что пусть балуются.

Позволь спросить, а если это будет не Rust, то Вася реализует T для S, Петя T для S, Ваня T для S, и т.д.?

Нет уж, пусть лучше владельцы T или S реализуют T для S.

Позволь спросить, а если это будет не Rust, то Вася реализует T для S, Петя T для S, Ваня T для S, и т.д.?

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

Нет уж, пусть лучше владельцы T или S реализуют T для S.

Аминь.

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

Ладно, ты не понял, объясню ещё раз.

Вася реализовал T для S в пакете A.
Петя реализовал T для S в пакете B.
Ваня реализовал T для S в пакете С.

Ты используешь пакеты A, B и C.

Какую из реализаций ты будешь использовать?

Как указать компилятору, что именно эту реализацию использовать? Может что-то типо?

// crate X
trait T {}

// crate A
impl T(impl_identifier) for S {}

// your crate
use A::impl_identifier;

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

Трейт и структура объявлены в др. пакетах.

И?

Если есть:

mod C {
  impl A::T for B::S { ... }
}

А если сделаешь?

use a; // impl T for S
use c; // impl T for S

Так здесь проблемы нет до тех пор, пока я не создам объект B::S и не попытаюсь привести его к A::T. Вот в этом случае компилятор может сказать, что приведение неоднозначно.

Собственно, в C++ вы можете определить int f(int) в пространствах имен A и B. Если вы сделаете using namespace A и using namespace B одновременно, то не сможете просто вызвать f(0). Вам придется уточнить имя f.

По-моему, вы оба неправы, а проблема в этом: http://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan-impls/

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

«Набор функций» в интерфейсе - это и есть поведение, а их реализация - это уже другой шаг. Ты можешь сколько угодно стрелять себе в ногу реализуя полеты в методе crawl. Это не одно и тоже, что прилепить новый интерфейс к тому же самому объекту. Вот я поэтому и пишу, что вы просто органически не отличаете интерфейс от реализации.

...и верно это для всех языков, кроме C...

не, серьёзно. до сих пор что-то никто не понимает, что крутизна C-либ не только в том, что быстрое, а ещё в том, что напишут к ним 20 биндингов и всё, оно везде, на всех языках. ради чего и небезопасность терпят...

до сих пор что-то никто не понимает, что крутизна C-либ

В самом Си нет крутизны - устаревший убогий язычок.

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

А говорить, что либы на Си круты потому, что у них относительно простой ABI - это оскорбление авторам либ.

В туевой хуче компилируемых языков можно экспортировать си-совместимый API. Даже в Go.
И хоть обмажься биндингами.

P.S. А если писать на Vala, они еще и сами сгенерятся

я к тому, что на какой-нить яве это хрен сделаешь...