Войти
ФлеймФорумПрограммирование

Статическая типизация* - говно, и его уже не улучшить (2 стр)

Страницы: 1 2
#15
17:35, 9 сен. 2019

Panzerschrek[CN]
> В Rust завезли наследование? Вот это поворот!
Trait inheritance же, гуглится вообще без проблем.

Рассмотрим пример библиотеки ввода-вывода.


behavior TextSink
  function Write[t: Text]: Result[void, IOFailure]
end

behavior RichTextSink
  function WriteRich[t: Text, b: Bold]: Result[void, IOFailure]
end

implementation of TextSink for RichTextSink
  function Write[t: Text]: Result[void, IOFailure]
    return WriteRich[t, false]
  end
end

struct HtmlEncoder
  local sink: TextEncoder
end

implementation of RichTextSink for HtmlEncoder
  function WriteRich[t: Text, b: Boolean]: Result[void, IOFailure]
    if b then
      t = "<b>" .. t .. "</b>"
    end
    return sink.Write[t]
  end
end

implementation of TextSink for HtmlEncoder
  function Write[t: Text]: Result[void, IOFailure]
    if b then
      t = "<span style=\"font-family:monospace\">" .. t .. "</span>"
    end
    return sink.Write[t]
  end
end


Реализация является ребром в том смысле, что это - отношение между двумя типами. В каком-то смысле, реализация задаёт соответствие - как один метод первого типа разворачивается в последовательность методов второго.
Терминология графов тогда позволяет формально описать, какая именно реализация будет выбрана, если есть альтернативы. Например, в иллюстрации выше, HtmlEncoder.Write может вызвать как метод из HtmlEncoder←TextEncoder (которая пишет моноширинным), так и из HtmlEncoder←RichTextEncoder←TextEncoder (которая пускает как есть).


#16
17:45, 9 сен. 2019

Вообще, задумка в том, чтобы явным и строгим образом разделить представление объекта и его поведение; а возможно даже - развязать состав структуры и её байтовый формат, что, например, позволило бы составить структуры данных с прозрачным SoA - например, пишешь a, b, c: Vector[Point] и затем a[2] = b[3] + c[4], а компилятор автоматически тебе делает ax, ay, az, ...: Vector[Float] и соответствующим образом подгоняет передачу и разыменовывание this в глубинах методов.

#17
19:45, 9 сен. 2019

Что мешает тебе так работать на С++?
Делаешь интерфейсы, через них работаешь, без прямого доступа к типу.
Если задача того требует, почему бы и нет... Всяко лучше, чем variant'ы городить.

#18
(Правка: 13:01) 12:56, 10 сен. 2019

Zab
Плюсы предрасполагают к намешиванию сотен концепций в одну кучу под названием "класс". Оно ещё более-менее держится, если все правила соблюдать вручную; но если всё делать вручную, то зачем тогда компилятор вообще нужен? А как только устные правила нарушаются - так сразу всё идёт по письке, наследование больше не наследует и https://rextester.com/FJCV82271
При моём подходе разные категории типов отвечают за совершенно разные аспекты объекта, а вместо общего понятия "наследует" используются более точные и узкие по смыслу "включает", "требует" и "реализует", с соответствующими ограничениями на использование. За счёт этого, получается система, где либо А "is-a" В во всех контекстах и везде работает, либо ни в одном А "is-not-a" В и они не пытаются изобразить какое-нибудь неполноценное подобие.

#19
(Правка: 11:27) 11:26, 12 сен. 2019

Delfigamer
А что тебе по этому поводу Шурик(MrShoor) говорит ? :)

#20
(Правка: 14:32) 14:30, 12 сен. 2019

Для COM такой подход вполне естественен. С ним, кстати, можно работать на большом множестве языков, не только на C++. Плюсы хороши только своей неограниченностью. Если чего не хватает - туда можно всегда добавить, слегка потрудившись, а не пытаться повеситься от обилия требуемых извратов.

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

Страницы: 1 2
ФлеймФорумПрограммирование