Rust 1.18

Информативно. Давно о таком мечтал. Предлагаю не ограничиваться полумерами, а вернуться к программированию напрямую в машинных кодах.

Это было сделано, чтобы сократить запись.

Напиши небольшой пример на C#, а люди подскажут как это делается в Rust.

using System;

namespace Test {
  class Base {
    public virtual void Test() {
      Console.WriteLine("a");
    }
  }
  
  class Derived : Base {
    public override void Test() {
      Console.WriteLine("b");
    }
  }
  
  class Programm {
    public static void Main(string[] args) {
      Base t = new Derived();
      t.Test(); // напечатает b
    }
  }
}

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

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

Например, Алан Кей, считает С++ не совсем языком с ООП.

возможно несколько наивный вопрос, а за чем алгоритмам знать какой тип к ним попал?

Реализациям алгоритмов в смысле. Например, в нашем ПО, есть классы счётчиков воды, электроэнергии и газа. Алгоритм получения расхода реализован в некой функции, у функции есть входные параметры в которых мы должны передать объекты счётчиков. У каждого объекта-счётчика есть метод который возвращает текущий расход. Но объекты имеют по историческим причинам разные классы родителей. В итоге нам придётся указать TObject и сравнивать получаемые объекты с поддерживаемыми и получать доступ к методу по средствам, типа

function GetCons(InputObj: TObject): ....
...
  if InputObj is TColdCounter then
    (InputObj as TColdCounter).GetConsumption
  else if InputObj is THotCounter then
    (InputObj as THotCounter).GetConsumption
...

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

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

Бред

Понял. В данном случае нужен интерфейс счётчика. Тогда у классов унаследованных от данного интерфейса можно будет дёргать метод без проблем. Правда

Но объекты имеют по историческим причинам разные классы родителей.

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

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

А что, в ваших Дельфях интерфейсов нет в принципе?

В данном случае нужен интерфейс счётчика.

Ну типажи в некотором смысле тоже интерфейсы =)

Например, Алан Кей

Это тот самый заварной чайник, который сводит весь смысл ООП к пересылке сообщений между объектами?

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

А что, в ваших Дельфях интерфейсов нет в принципе?

Всё есть там, но проект до меня ещё 10 лет пилили другие люди и ошибочных решений там миллион. А сейчас ни кто не даст время переделывать это...

Это тот самый заварной чайник, который сводит весь смысл ООП к пересылке сообщений между объектами?

Да тот чудак =)

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

Всё есть там, но проект до меня ещё 10 лет пилили другие люди и ошибочных решений там миллион. А сейчас ни кто не даст время переделывать это...

Блин, так с чего тогда такие причитания: «Если бы была возможность для этой задачи использовать типаж, то мы бы знали что есть метод и нам не важен был бы класс объекта.»

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

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

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

Напиши «бред» ещё раз пять. Растокод от этого не перестанет быть перегруженным сложночитаемым говнокодом.

Мне виднее, я с этим кодом и небольшой группой программистов уже 3 года работаю. Я гарантирую, что наличие типажей в Delphi/FPC упростило бы жизнь в миллионы раз.

Не читай его, раз тебе больно =)

Хотя, Вы правы. Ни кто и на это бы не дал время =(

В таком случае, странно на него ссылаться-то. Мы вроде про ООП говорим, а Алан Кей тут каким боком? То, что он свой смолтолк считает идеалом ООП - ну так мало ли кто чем болен.

а во-вторых это всё равно через одно место.

Почему?

Это не моя база кода. Я форкнул и успел сделать 3 коммита. Мне нужен был MIT-SHM для иксов, а это в свою очередь нужно для движка. Для рисования на плоскости из пикселей без OGL и прочего. Я для плюсов под пингвина искал аналог виндового DirectDraw. Ну чтоб пиксели и больше нечего. В итоге остановился на XShmPutImage. А этот тянет за собой разделяемую память posix.

Добавил в проект быстренько дюжину функций и пару структур - готово к использованию. Я не стал заморачиваться. Про bindgen слышу в первый раз. Что сильная вещь?!

Так я и не читаю. Мне интересно, почему его так агрессивно защищают, говоря, что он легко читается. Вдруг я какую-то тайную фишку упустил.

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

Как всегда всё упирается в определение ООП.
И там правильно сказано «ООП которое совсем не такое как в С++»
Т.к. абстракция,инкапсуляция, наследование и полиморфизм есть.
Правда последние два только для трейтов.

А ты хочешь как С++, а это не C++.

Поэтому я и говорю, что бессмысленный срачЪ.

rust это ооп или нет?

В привычном и устоявшемся понимании — нет. Можно долго разводить демагогию про Кеевский ООП, про то, что он разный и вообще в C++ не правильный ООП, но простой ответ: нет, Rust это не ООП язык.

Типажи в расте как бы и есть интерфейсы как в решетке, но только наоборот. В решетке мы делаем интерфейс, а потом класс. В расте наборот - если же есть класс, то к нему можно присобачить интерфейс. При этом сам класс об этом не знает. Можно добавлять методы класса не используя наследования.

И это не ломает логики даже для примитивных встроенных типом. Можно добавить методы для целого 32-битного.

Именно поэтому наследование выглядить как impl A for B.

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

Но это все тоже ООП с методами, с внтренним состоянимем и инкапсуляцией объектов.

В таком случае, странно на него ссылаться-то. Мы вроде про ООП говорим, а Алан Кей тут каким боком? То, что он свой смолтолк считает идеалом ООП - ну так мало ли кто чем болен.

Это к теме того, что есть разные формулировки ООП и под некоторые Rust попадает.

инкапсуляцией объектов

Ну справедливости ради, это не совсем так. В Rust единица инкапсуляции — модуль, а не структура/трейт.

Так я и не читаю. Мне интересно, почему его так агрессивно защищают, говоря, что он легко читается. Вдруг я какую-то тайную фишку упустил.

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

А вот ядро вполне себе может быть не проверено

Когда мы или кто-то другой будет писать новый софт, он заузает наш ЯП и все будет «зашибись». С уже написанным софтом «зашибись» не будет никогда, потому что даже если взять и исправить все проблемы, к нему будет более применим термин «переписанный софт», что по сути ~= «новый софт».

Согласен!

С уже написанным софтом «зашибись» не будет никогда

То есть не смотря на то что всё равно какие файлы с плюсами проверять старые не проверить?

А как же ключевое слово pub и его отсутствие? Разве оно не обрамляет собой объект?

Ваши споры нелогичны тем, что для вас ООП это обязательно некий стандарт программирования или поддержка d zpsrt синтаксическим сахаром. Но ведь это все подходы. На C тоже можно в ООП. Есть даже некая экзотика как GObject от Glib. Просто подход. В решетке есть свойства, но это не значит что так нельзя сделать на плюсах. Некоторые JS макаки считают что их язык функциональный. Видимо они не видели хацкеля.

Вы не поверите, но это в большинстве языков так.

Которое я никому не навязываю.

Чел, ты тролль. И ты именно навязываешь. Потому что не способен ответить на один простой вопрос: Тебе-то что до этого?

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

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

Когда-то мейнстримом было пренебрежительно относиться к JavaScript. А уж прототипный ООП никак не назовёшь простым и легко осваиваемым. И? Это кого-то остановило?

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

Так что ты просто тролль, который хочет срач.

Одно дело - чинить плюсовый код. Другое - запилить замену С++ на 22 век.

С++ устарели, на сколько Rust подойдёт для его смены узнаем через года. Может кто-то запилит более мощный язык или более простой - хз. Но программист на С++ КМК частично занимается баданием с С++ вместо полезных действий. А многие вещи в С++ уж действительно выглядят как костыли, например, сколько сейчас типов указателей и строк в С++?

В общем, я рассчитываю на то, что появиться замена C++ и многие думают тут об этом же, и КМК Rust имеет шансы на это.

Мне нужен доступ к полю test. чяднт?

trait SillyPrinter {
    fn foo(&self) {
        println!("a");
    }
}

impl SillyPrinter for u32 {}

struct Derived {
    test : u32,
}

impl SillyPrinter for Derived {
    fn foo(&self) {
        // don't call a base. We don't need it
        // self.0.foo();
        println!("b");
    }
}

fn main() {
    let t: Box<SillyPrinter> = Box::new(Derived { test: 0 });
    println!("{}", t.test);
}

У SillyPrinter нет поля test

Как поправить? В случае с c# мне не надо дополнительно заморачиваться, ко всему что public есть доступ.

добавь аксессор

В случае с c#

В случае с c# тебе надают по рукам за прямой доступ к полю

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

Если в родительском классе не определено поле test, то как ты к нему получишь доступ?

Сделали мой вечер. Вам нужна подсказка, как закрыть вкладку с обсуждением и не тратить время? ;-) Или силы воли не хватает?

В случае с c# тебе надают по рукам за прямой доступ к полю

Кто? Можно же и к свойству применить.

В случае необхоимости я могу привести к базовому классу?

не знаю есть ли в шарпе интерфейсы.

Есть.

А как же ключевое слово pub и его отсутствие? Разве оно не обрамляет собой объект?

Можно заметить, что внутри модуля pub — всё. То есть модификаторы играют роль только при импорте модуля и использовании его внутренностей.

Ваши споры нелогичны тем, что для вас ООП...

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

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

Два чая.

Вам нужна подсказка, как закрыть вкладку с обсуждением и не тратить время?

А так я здесь, в отличии от вас, не страдаю. Я жую попкорн и наблюдаю за вашим срачем. Изредка позволяя себе реплики из зала. :)