Rust 1.12

Лол, а кто говорит что там должен быть принт(приветмир)? А либа, кстати, да - ошибка такая же, но вид имеет другой click. Честное слово компилил не либу :D

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

не хватает того, чтобы компилятор давал по рукам за нарушения

Как насчет pimpl ? Всякие там абстрактные FILE*

А в чем разница между этим и этим?)
Хз, первый раз такое вижу. Попробуй все таки воспроизвести в минимальном примере

Ожидание: DSL. Реальность: на редкость ужасненький DSL.

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

На первом скрине компилилась библиотека с fn main(){}, на втором бинарь. Сорян, код не могу показать, вдруг мне за него шекелей дадут по багбаунти))

P.S. Эдак и С, и asm — OOP.

Минимальный пример, воспроизводящий ошибку != твой топ сикрет код
UPD: а, лол, ты хочешь за багофиксы раста чтобы тебе деньжат отвалили? Ты отвратителен, если честно.

Ок-ок, только не нервничай) А что плохого в вознаграждении за найденные ошибки?

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

прибегнуть к схоластике и доказать, что упомянутая троица — это не ООП.

нет, не так. упомянутая троица — всего лишь один из возможных вариантов, и не столько собственно ООП , сколько некоторой (весьма убогой и ограниченной) объектной модели «как в Simula/Beta/C++».

в других объектных моделях есть более другие наборы фич. например, двоица: «мультидиспетчеризация и мультифорвардинг сообщений» в COS (CLOS для С). или «мультиметоды и метаобъектный протокол» в CLOS. или: «сокрытие реализации и расширяемые записи, полиморфизм модулей» в оберон-2. или «метакласс как first class object и динамическая диспетчеризация сообщений» в смоллток. или «прототипное ООП» в Self, JavaScript.

это всё — разные механизмы (объектные модели) реализации ООП как идеи, концепции, парадигмы «повторно используемых модулей, с first class object новой сущностью (объектом), проверяемой системой типов (этих объектов)»

Если это все в языке X из коробки — значит язык X можно назвать ООЯ. Нет — значит нельзя.

«из коробки» не существенно. ибо в нормальных языках ты сам можешь создавать такие first class object и расширять систему типов.

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

ООЯ != «ООП как в С++»

«поддерживает ООП» (но допускает без) и «first class object = объекты в ООП» не одно и тоже.

идея != механизм реализации идеи (один из вариантов). но включает, охватывает.

UPD: а, лол, ты хочешь за багофиксы раста чтобы тебе деньжат отвалили? Ты отвратителен, если честно.

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

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

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

Соглашусь, но только это _очень_ частный случай. Настолько частный, что для него можно даже сделать нормальный code completion. (Для Ъ-сообщений это где-то в окрестности невозможного).

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

Выше написал. Одно дело когда работу заказали, другое — «я тут баг нашел, но я вам о нем не скажу, пока не заплатите N шекелей»

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

вот кстати, параметрические пакеты в Ada (параметризованные другими пакетами, например) и сигнатуры/функторы/типы модуля в модульной системе ML — это вот эти высокоуровневые модули как first class objects. «функторы модуля» как интерфейсы в ООП.

В эту же сторону и концепты.

да. см. например в MirageOS Unikernel реализацию драйверов,tcp/ip стека во время компиляции (параметризованных функторами, интерфейсами, концептами, как не назови — идея одна).

Ой, да и пусть не говорит. Когда этот баг кому-то реально помешает, его запостят в багтрекер, и рано или поздно починят без участия нашего красавчика. Или даже с участием. Не всё ли равно?

Собака лает, караван идет.

Ок.

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

ну да, интерфейсы более высокоуровневая конструкция, чем механизм её реализации через наследование. например, в Go ad-hoc интерфейсы есть, а наследования нет. в Rust и наследование есть.

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

«метакласс как first class object и динамическая диспетчеризация сообщений» в смоллток. или «прототипное ООП» в Self, JavaScript.

Вы батенька читать умеете? Если умеете, то перечитайте тред, я писал и про SmallTalk, и про Self, и про JavaScript. Что характерно, во всех этих языках есть и наследование, и инкапсуляция, и полиморфизм. Только делается по-разному.

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

Я не часть сообщества, говорю же - взял потыкать. А оно, мало того что нечитаемое, так еще и забагованое. Прошу немного, долларов 200, резину надо менять, винтер из каминг)

Прошу немного, долларов 200

Взоржал. Напиши потом, если тебе их кто-нибудь за этот баг заплатит :D

Что характерно, во всех этих языках есть и наследование, и инкапсуляция, и полиморфизм. Только делается по-разному.

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

наследование как самый жёсткий тип связи «не интересно ни разу».

Ну че ты сразу( Может фанбои захотят скинуться.

Работу найти не пробовал?

Неа, не пробовал.

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

Он вроде Rust и не интересуется.
Энивей, пока не видел, но я и не отслеживаю. Но видно, что в вакансиях начинает проскакивать что-то вроде «кодим мы на питоне, но если есть опыт в go/rust/langname — будет круто».
UPD: у яндекса на хэдхантере висит вакансия на системного Linux погроммиста на C, C++ / Rust

Я интересуюсь растом в равной мере с го, ди и окамлом. Но это не значит что я офисный программист 10 борщей из 10. Ты быстрее потеряешь интерес к расту, чем найдешь на нем работу. Через год-два придумают новый <lang-name> и вы побежите на него, а про раст забудете. Еще через пару лет вспомните про лисп и так по кругу.

UPD: у яндекса на хэдхантере висит вакансия на системного Linux погроммиста на C, C++ / Rust

Ты бы еще майлрушку предложил. Совсем уважение к себе потеряли.

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

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

но да, это уже не С++.

Я выше кидал ссылку на растбук, там все подробно описано

где?

Надо ж, сдвинулось с мертвой точки. Лепота

Так, я не понимаю, каким боком принцип подстановки Лисков относится к нарушению инкапсуляции, например, в этом случае:

в этом случае не относится, т.к. не изменяет инвариант класса и контракты. но если контракты нарушаются, то возникает.

Принцип был сформулирован Барбарой Лисков и Джаннетой Винг в следующем виде: «Пусть q(x) – доказуемое свойство объекта x типа Т. Тогда q(y) должно быть доказуемо для объектов y типа S, где S – подтип типа Т».

Пример из «проектирования по контракту»:
* Предусловия не могут быть усилены в подтипе(потомке)
* Постусловия не могут быть ослаблены в подтипе
* Инварианты супертипа(предка) должны сохранятся для подтипа
* «правило истории»: объекты изменяются только через вызов методов.

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

понятно, что раз в С++ нельзя гарантировать свойства про предусловия, постусловия, инварианты (из-за произвольного расширения), то про «доказуемость свойств» тут всё плохо, и «правило истории» тут не поможет (в отличие от того же Eiffel с проверяемыми в CTFE контрактами и ограничениями контрактов).

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

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

Держи еще раз и тут еще раздел в гайдлайнах

Ты быстрее потеряешь интерес к расту, чем найдешь на нем работу. Через год-два придумают новый <lang-name> и вы побежите на него, а про раст забудете.

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

яндекс
Ты бы еще майлрушку предложил. Совсем уважение к себе потеряли.

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

Спасибо за ликбез, но мне кажется, что вы о чем-то своем, наболевшем.

И да:

в отличие от того же Eiffel с проверяемыми в CTFE контрактами и ограничениями контрактов

Давно Eiffel научился контракты в компайл-тайм проверять? Или вы это вычитали там же, где и формальное определение принципа подстановки Лисков?

Давно Eiffel научился контракты в компайл-тайм проверять?

подразумевается композиция контрактов предка и потомка через нестрогие or else или and then и явный запрет через строгие операции — правило утверждения переобъявления (assertion redeclaration) (см. книги Б. Мейера), также Принцип динамического связывания

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

(и далее его рассуждения в терминах пред/постусловий и инвариантов), и далее его рассуждения о том, что virtual должен выводить компилятор автоматически, а не писать программист руками, также ковариантность и опорный элемент (like anchor).

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

ковариантность и like anchor например — проверяемы статически. есть ещё ряд ограничений типа «принцип ХХХ», тех же catcalls, и т.п. которые в совокупности и составляют «метод Eiffel» — опять же, для минимизации динамики и проверки статически.

(семантику владения/одалживания в раст, например можно считать тоже одним из таких принципов, составляющих уже «метод Rust», например. другое дело, что в «методе Eiffel» таких принципов довольно много и их не так просто запомнить, в «методе Rust» + HKT эта система правил может быть более «ортогонализированной»)

по идее, здесь нужно что-то вроде типов высшего порядка. и функциональных объектов, вычисляемых во время компиляции. и предикатов типа, с кодировкою вычисляемой CTFE. и каких-то интерфейсов между такими ф.о.,системой типов и модулями. или тех же контрактов над такими вот интерфейсами (трейты, ау) — обеспечивающих composable и compositable.

и вот тогда получается уже model checking для такой «объектной модели языка», доказуемый для семантики (которую надо задавать каким-то метаязыком над).

Чувак, хватить жить в стране розовых пони и срать радугой. Скачайте себе EiffelStudio, наколбасьте тысяч эдак 20 строк на Eiffel-е и увидите, что все гораздо прозаичнее.

Вялая какая-то дискуссия. Сравните: https://habrahabr.ru/company/jugru/blog/308914/

Обсуждают Ѣ-ООП. Пример прогрессивного кода:

public int max(int a, int b) {
  return new If(
    new GreaterThan(a, b),
    a, b
  );
}

Может, ну его, этот ООП? Какое-то он странное влияние на мозг оказывает.

подгорания зафиксирован в первом комменте к новости

То есть констатация факта слома совместимости в первом посте должна свидетельствовать о подгорании?

Не понял, объясни.

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

Я другой анонимус, но вставлю 5 копеек.

Тут проблема есть. Крупные компании обычно потеряли команду. Работает толпа не заинтересованных в кооперации людей. Жуткая среда. Денег платят меньше. Требований больше. Куда не глянь - одни минусы. Есть только один плюс, если ты плохой программист но хочешь много зарабатывать - иди туда. Работай локтями (на других) и языком (на жопу начальства), и, может быть, будешь получать больше.

Нет, страна пони это там: https://github.com/ponylang/ponyc

Тут измерение ржавых аппаратов Елизарова!

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

ввиду текучки

Ага. Не зря ее вспомнили. Судя по всему, есть во всех....

И да.

Крупные работадатели дают возможность довольно быстрого горизонтального и вертикального роста

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

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

Профессионализм подразумевает способность хорошо общаться с коллегами (written and verbal communication skills). Аутисты и прочие асоциальные личности, в этом плане, конечно, ущемлены.

Профессионализм подразумевает способность хорошо общаться с коллегами (written and verbal communication skills). Аутисты и прочие асоциальные личности, в этом плане, конечно, ущемлены.

Хорошее общение подразумевает умение коллег подставить и вылизать жопу начальству?

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

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

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

Сам по себе, не нарушает, но даёт возможность её нарушить. Наследник может сделать public: using A::private_data;.

Собственно вся эта пурга с private/protected/friend была добавлена в C++ не от хорошей жизни, а от отсутствия модулей

Не думаю, что модули заменяют protected, по моему, это сильно разные вещи. Другое дело, что использование protected можно считать признаком плохого дизайна, хотя тут можно и поспорить.

Ну у товаrища такая мулька, что если нету protected, то и нету инкапсуляции.

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