Re[16]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 13:43
Оценка:
Здравствуйте, Serginio1, Вы писали:

P>>Тамошние инициализаторы, кстати говоря, довольно убогие.

P>>Я бы предпочел инициализатор навроде такого

P>>
P>>Form {
P>>   header: {content: aaa} 
P>>   main: { 
P>>     list: [
P>>      ItemA {id: 'a', content: yyy },
P>>      ItemB {id: 'a', content: zzz },
P>>    ]
P>>   },
P>>   footer: OkCancelFooter {onOk: onOkHandler, onCancel: onCancelHandler, onDispose: onDisposeHandler}
P>>} 
P>>


P>>Глядишь, с таким инициализатором не пришлось бы городить огород типа XAML


S> XAML это про декларативность. То есть за строкой скрывается куча кода.


Именно это и есть в моем примере

S> Ну а в приведённом тобой коде это экономия на new.


Вы сначала накидайте полный эквивалент в c# а уже потом сравнивайте
Re[17]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.04.24 13:59
Оценка:
Здравствуйте, Pauel, Вы писали:

S>> XAML это про декларативность. То есть за строкой скрывается куча кода.


P>Именно это и есть в моем примере

Нет это конструкторы. Ты явно не использовал XAML
S>> Ну а в приведённом тобой коде это экономия на new.

P>Вы сначала накидайте полный эквивалент в c# а уже потом сравнивайте


Form form = new() {
   header: new() {content: aaa} 
   main= new() { 
    list new(){
      ItemA = new() {id= 'a', content= yyy },
      ItemB = new() {id= 'a', content= zzz },
   }
   },
   footer= OkCancelFooter {onOk= onOkHandler, onCancel= onCancelHandler, onDispose= onDisposeHandler}
}


ил если есть конструкторы (object content)
Form form = new() {
   header: new(content: aaa)
   main= new() { 
    list new(){
      ItemA = new(id: 'a', content: yyy ),
      ItemB = new(id: 'a', content: zzz ),
   }
   },
   footer= OkCancelFooter {onOk = onOkHandler, onCancel= onCancelHandler, onDispose= onDisposeHandler}
}
и солнце б утром не вставало, когда бы не было меня
Отредактировано 04.04.2024 14:13 Serginio1 . Предыдущая версия . Еще …
Отредактировано 04.04.2024 14:12 Serginio1 . Предыдущая версия .
Отредактировано 04.04.2024 14:06 Serginio1 . Предыдущая версия .
Re[16]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 14:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Давайте возьмём более-менее любую популярную библиотеку и посмотрим, сколько конструкторов у привычных нам объектов.

S>Например, какой-нибудь FileStream. Или тот же DateTime.

DateTime плохой пример. DateTimeOffset — 8 конструкторов. Я в свое время задолбался писать конформанс тесты под один из сервисов на дотнете и джаве — у них вечно были ошибки с рендерингом выхлопа с датами.
Визуально, по коду, разницы между двумя вариантами почти что нет — код ревью не работает. А покрыть тестами все нюансы со временем мягко говоря задача не маленькая.

S>А в-четвёртых, если вы хотите посмотреть на приложение, в котором на таком месте задаётся структура типа DOM, то запустите Visual Studio.

S>Там весь редактор кода — это иммутабельное дерево поверх иммутабельного дерева.
S>И все инспекторы и codefix-провайдеры работают с этим иммутабельным деревом именно через всякие root.ReplaceNode(classDeclaration, classDeclaration.AddModifiers(items)).
S>Вполне себе всё это шустро работает, и GC им не мешает .

Подозреваю, они напилили там целую кучу оптимизаций под гц, что бы не было лишних переаллокаций. В 00х у них было полно проблем с перформансом, память могла уходить гигабайтами на ровном месте. Потом вероятно привели всё в порядок.
Re[18]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 14:24
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

P>>Именно это и есть в моем примере

S>Нет это конструкторы. Ты явно не использовал XAML

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

Сам по себе XAML не летает — это просто фронтенд для описания структуры.
А далее готовая структура подаётся в бакенд, который её интерпретирует.

Декларативные свойства обеспечивают не xaml, а тот самый бакенд.
Собственно, вместо XAML вы можете использовать что угодно, абы структура на выходе была такая же.
Вы можете и сейчас это сделать разными путями
1. создавать структуру на основе более внятного ДСЛ, нежели xaml, транслируюя в xaml
2. императивно
3. на основе инциализаторов, которые кривые, что вы и продемонстрировали

То есть, буде в наличии внятные инциализаторы, нет необходимости городить огород из XAML

S>>> Ну а в приведённом тобой коде это экономия на new.


P>>Вы сначала накидайте полный эквивалент в c# а уже потом сравнивайте


S>bkb

S>
S>Form form = new() {
S>   header: new(content: aaa)
S>   main= new() { 
S>    list new(){
S>      ItemA = new(id= 'a', content= yyy ),
S>      ItemB = new(id= 'a', content= zzz ),
S>   }
S>   },
S>   footer= OkCancelFooter {onOk = onOkHandler, onCancel= onCancelHandler, onDispose= onDisposeHandler}
S>}
S>


Итого — по вашему коду не сильно видна разница между объектами и списками, + шум new()

Кроме того, у вас вероятно ошибка
Вот здесь создаем список у которого два элемента, один с типом ItemA, второй ItemB
[
      ItemA {id: 'a', content: yyy },
      ItemB {id: 'a', content: zzz },
]
Отредактировано 04.04.2024 14:28 Pauel . Предыдущая версия .
Re[19]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.04.24 15:05
Оценка:
Здравствуйте, Pauel, Вы писали:

P>>>Именно это и есть в моем примере

S>>Нет это конструкторы. Ты явно не использовал XAML

P>Подозреваю, я xaml попробовал задолго до того, как вы про него узнали Не впечатлил — громоздко, многословно, тормозно

Там есть конвертеры, тригеры итд.
Я шарпом занимаюсь с 2002 года. И сначала XAML у меня вызвал отвращение.
Да я и не особо дизайнер.

P>Сам по себе XAML не летает — это просто фронтенд для описания структуры.

P>А далее готовая структура подаётся в бакенд, который её интерпретирует.

Ну вообще то он компилируется Компиляция XAML

P>Декларативные свойства обеспечивают не xaml, а тот самый бакенд.

P>Собственно, вместо XAML вы можете использовать что угодно, абы структура на выходе была такая же.
P>Вы можете и сейчас это сделать разными путями
P>1. создавать структуру на основе более внятного ДСЛ, нежели xaml, транслируюя в xaml
P>2. императивно
P>3. на основе инциализаторов, которые кривые, что вы и продемонстрировали

P>То есть, буде в наличии внятные инциализаторы, нет необходимости городить огород из XAML

Я так же программно иногда делаю.
Но это от лени. Я не так часто его использую.

S>>>> Ну а в приведённом тобой коде это экономия на new.


P>>>Вы сначала накидайте полный эквивалент в c# а уже потом сравнивайте


S>>bkb

S>>
S>>Form form = new() {
S>>   header: new(content: aaa)
S>>   main= new() { 
S>>    list new(){
S>>      ItemA = new(id= 'a', content= yyy ),
S>>      ItemB = new(id= 'a', content= zzz ),
S>>   }
S>>   },
S>>   footer= OkCancelFooter {onOk = onOkHandler, onCancel= onCancelHandler, onDispose= onDisposeHandler}
S>>}
S>>


P>Итого — по вашему коду не сильно видна разница между объектами и списками, + шум new()

Ну можно
 list = new List<object>

а new кому то шум, а кому то явное определение

P>Кроме того, у вас вероятно ошибка

P>Вот здесь создаем список у которого два элемента, один с типом ItemA, второй ItemB
P>
P>[
P>      ItemA {id: 'a', content: yyy },
P>      ItemB {id: 'a', content: zzz },
P>]
P>


ну значит будет
      new ItemA() {id= 'a', content= yyy },
      new ItemB() {id= 'a', content= zzz },


или если есть конструктор с параметрами id и content

      new ItemA(id: 'a', content: yyy),
      new ItemB(id: 'a', content: zzz ),


Это не особо принципиально. Это из области флаттера и Dart . У Котлина тоже такое есть.
Но XAML он не для программистов, а дизайнеров. Изначально идея была отделить дизайнеров и программистов
и солнце б утром не вставало, когда бы не было меня
Re[20]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.04.24 15:42
Оценка:
Здравствуйте, Serginio1, Вы писали:

P>>Подозреваю, я xaml попробовал задолго до того, как вы про него узнали Не впечатлил — громоздко, многословно, тормозно

S>Там есть конвертеры, тригеры итд.

Спасибо, не надо — там где хватает обычного вызова функции надо намастырить кусочек xml

P>>Сам по себе XAML не летает — это просто фронтенд для описания структуры.

P>>А далее готовая структура подаётся в бакенд, который её интерпретирует.

S> Ну вообще то он компилируется Компиляция XAML


И что с того? Это всё равно описание структуры. Всю работу делает бакенд.
Во что именно xaml компилируется, в вызовы типа "parent.addElement(...)" ? Если так, то никаких преимуществ перед инициализаторами нет.
Если во чтото более низкоуровневое — тут слабо верится.

S> Это не особо принципиально. Это из области флаттера и Dart . У Котлина тоже такое есть.

S>Но XAML он не для программистов, а дизайнеров. Изначально идея была отделить дизайнеров и программистов

Подозреваю, в микрософте была идея, что над кодом будут работать дизайнеры и программисты
А прогресс пошел по другому пути — начали плодиться разрешения от 320x200 до 8K, десятками тысяч и дизайнерам уже было не до кода — успеть бы картинок нарисовать.
Лайоут типа респонзив итд у микрософта был непредусмотрен, соответсвенно видение микрософта умерло вместе с ихними инструментами для рисования ui.

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

То есть вот такой стек у нас выходит
1 данные
2 семантический рендеринг
3 стили
4 лайоут, композиция
5 реакция и поведение

технически 4 и 3 делают одним и тем же инструментом, но реально это трохи разные вещи. стили это look & feel, layout это взаимодействие элементов

У микрософта 2, 3 и 4 это Винигрет, до кучи многословный

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

Почему так произошло — потому что спрос на фронтенд всё время растет, фронтенд становится сложнее с т.з. требований. А раз растет сложность требований, то очевидно и внутренняя структура будет меняться точно так же — будет усложняться.
Re[21]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.04.24 17:04
Оценка:
Здравствуйте, Pauel, Вы писали:

P>>>Подозреваю, я xaml попробовал задолго до того, как вы про него узнали Не впечатлил — громоздко, многословно, тормозно

S>>Там есть конвертеры, тригеры итд.

P>Спасибо, не надо — там где хватает обычного вызова функции надо намастырить кусочек xml

XAML это в том числе и визуальный редактор. Ты сразу видишь результат, интеллисенс итд.

P>>>Сам по себе XAML не летает — это просто фронтенд для описания структуры.

P>>>А далее готовая структура подаётся в бакенд, который её интерпретирует.

S>> Ну вообще то он компилируется Компиляция XAML


P>И что с того? Это всё равно описание структуры. Всю работу делает бакенд.

P>Во что именно xaml компилируется, в вызовы типа "parent.addElement(...)" ? Если так, то никаких преимуществ перед инициализаторами нет.
P>Если во чтото более низкоуровневое — тут слабо верится.
Ну вот в то, что ты пишешь вручную без редактора.

S>> Это не особо принципиально. Это из области флаттера и Dart . У Котлина тоже такое есть.

S>>Но XAML он не для программистов, а дизайнеров. Изначально идея была отделить дизайнеров и программистов

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

P>А прогресс пошел по другому пути — начали плодиться разрешения от 320x200 до 8K, десятками тысяч и дизайнерам уже было не до кода — успеть бы картинок нарисовать.
P>Лайоут типа респонзив итд у микрософта был непредусмотрен, соответсвенно видение микрософта умерло вместе с ихними инструментами для рисования ui.

P>Для ui разработчиков нужно максимальное разделение концепций — отделить даные, лайоут, стили, рендеринг и поведение.


P>То есть вот такой стек у нас выходит

P>1 данные
P>2 семантический рендеринг
P>3 стили
P>4 лайоут, композиция
P>5 реакция и поведение

P>технически 4 и 3 делают одним и тем же инструментом, но реально это трохи разные вещи. стили это look & feel, layout это взаимодействие элементов


P>У микрософта 2, 3 и 4 это Винигрет, до кучи многословный


P>Вещи из п1-5 могут деливериться каждый по отдельности, буквально. До момента деплоя вы можете никогда не видеть вон те стили и вон тот лайоут на тех данных с таким вот поведением.


P>Почему так произошло — потому что спрос на фронтенд всё время растет, фронтенд становится сложнее с т.з. требований. А раз растет сложность требований, то очевидно и внутренняя структура будет меняться точно так же — будет усложняться.


Фронтэнд это для браузеров. Для десктопа нужны другие инструменты.

Но, что я не вижу особо альтернатив. Может XAML заменить на YAML.
Суть она должна быть удобна для дизайнеров. Но прошло столько лет, а XAML никуда не делся.
Тот же MAUI на XAML
и солнце б утром не вставало, когда бы не было меня
Re[22]: Базовое отличие ООП от ФП
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.04.24 14:41
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

P>>Спасибо, не надо — там где хватает обычного вызова функции надо намастырить кусочек xml

S>XAML это в том числе и визуальный редактор. Ты сразу видишь результат, интеллисенс итд.

Такой редактор можно прикрутить к чему угодно — такое понаписывали чуть ли не на все случаи жизни, наверное на всех языках есть
Инициализаторы это json подобный язык — проще просто некуда
У xaml сверх этого нет ни единого преимуществе

Apple вон вовсе выдал SwiftUI — шикарная вещь. Может не самая идеальная, но уж точно лучше xaml

P>>Если во чтото более низкоуровневое — тут слабо верится.

S> Ну вот в то, что ты пишешь вручную без редактора.

не смешите людей — редактор даже на основе тупого кода в winforms прикрутили, а вы трясетесь, что json подобный язык вдруг станет препятствием

S>Суть она должна быть удобна для дизайнеров. Но прошло столько лет, а XAML никуда не делся.


Дизайнеры с кодом не работают. Им не до этого — задача дизайнера не xaml выдать, а нарисовать картинки на все случаи жизни, размеры экрана итд.
XAML никуда не делся потому, что его чисто технически нечем заменить
1. в языке нет ничего внятного, что может послужить заменой
2. в рантайме хилые средства, приходится мастырить грабли типа attached property, конвертеры, триггеры итд.

> Для десктопа нужны другие инструменты.


Очень смешно — софта на веб-технологиях появляется всё больше. pva стали нормой. electron прижился. сапр и те потиху идут в веб.
Чисто десктопный софт теперь это узенькая ниша инструментов которые идут вместе с системой.
Re[8]: Базовое отличие ООП от ФП
От: _NN_ www.nemerleweb.com
Дата: 28.04.24 12:53
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, _NN_, Вы писали:



_NN>>C++.

_NN>>&& означает, что функция может применяться исключительно к временному объекту.

S> Вот же извращенцы! И до такого надо ещё додуматься!

S>А почему не в конструкторе?

В чём собственно вопрос ?
C++ позволяет гибко указать когда функция может применяться к объекту:

https://gcc.godbolt.org/z/jTescMb8K
struct A {
    void non_const() { }

    void const_() const { }

    void ref() & { }
    
    void rvalue_ref() && { }

    void ref_const() const & { }

    void rvalue_ref_const() const && { }
};

int main()
{
    // ------
    // lvalue
    A lvalue;
    
    lvalue.non_const();
    lvalue.const_();
    lvalue.ref();
    // lvalue.rvalue_ref(); // Error
    lvalue.ref_const();
    //lvalue.rvalue_ref_const(); // Error

    // -----
    // const lvalue
    const A const_lvalue;
    
    // const_lvalue.non_const(); // Error
    const_lvalue.const_();
    // const_lvalue.ref(); // Error
    // const_lvalue.rvalue_ref(); // Error
    const_lvalue.ref_const();
    // const_lvalue.rvalue_ref_const(); // Error

    // -----
    // rvalue
    A().non_const();
    A().const_();
    // A().ref(); // Error
    A().rvalue_ref();
    A().ref_const();
    A().rvalue_ref_const(); // Error

    // -----
    A&& rvalue = A();

    rvalue.non_const();
    rvalue.const_();
    rvalue.ref();
    // rvalue.rvalue_ref(); // Error
    rvalue.ref_const();
    // rvalue.rvalue_ref_const(); // Error   

    // -----
    const A&& const_rvalue = A();

    // const_rvalue.non_const(); // Error
    const_rvalue.const_();
    // const_rvalue.ref(); // Error
    // const_rvalue.rvalue_ref(); // Error
    const_rvalue.ref_const();
    // const_rvalue.rvalue_ref_const(); // Error   
}


Ну и для упрощения однотипных функций ввели Deducing this.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[8]: Базовое отличие ООП от ФП
От: _NN_ www.nemerleweb.com
Дата: 28.04.24 12:56
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А как из этого изготовить хоть что-то полезное?

S>Например, вот такое тоже не работает:

S>
S>...
S>auto m2 = m.setField(2);
S>

S>А это, собственно, и есть одна из основных конструкция ФП.

Никак. В прочем об этом уже и написали.

Чтобы работало m.setField нужны перегрузки для lvalue '&', что подводит нас просто к паттерну Builder или к конструктору если нужна неизменяемость.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[3]: Базовое отличие ООП от ФП
От: Ночной Смотрящий Россия  
Дата: 29.04.24 09:25
Оценка:
Здравствуйте, novitk, Вы писали:

N>https://github.com/ghc/ghc

N>https://github.com/JuliaLang/julia/tree/master/stdlib
N>https://github.com/scala/scala3

Компиляторы — крайне фиговый пример, потому что специфика в полный рост, причем специфика такая, что нигде больше в больших объемах не встречается.
А так да, на компиляторах ФП максимально демонстрирует свои преимущества. А вот если брать мейнстримовый мейнстрим, то на тех же задачках из области CRUD (и в целом на задачах, в которых несколько моделей с преобразованиями) все становится совсем не очевидным.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: Базовое отличие ООП от ФП
От: Ночной Смотрящий Россия  
Дата: 29.04.24 09:29
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>ООП это когда данные и функции объединяются в одну сущность.


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

vsb>Подходы друг с другом никак не пересекаются и одно другому никак не мешает.


Некоторое пересечение все же есть, хотя бы потому что для одной задачи обычно существует как функциональное, так и ООП решение.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.04.24 11:43
Оценка:
Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, Serginio1, Вы писали:


S>>Здравствуйте, _NN_, Вы писали:



_NN>>>C++.

_NN>>>&& означает, что функция может применяться исключительно к временному объекту.

S>> Вот же извращенцы! И до такого надо ещё додуматься!

S>>А почему не в конструкторе?

_NN>В чём собственно вопрос ?

_NN>C++ позволяет гибко указать когда функция может применяться к объекту:

https://rsdn.org/forum/philosophy/8725074.1
Автор: Serginio1
Дата: 04.04 13:44

Именованные и необязательные аргументы (Руководство по программированию на C#)


Есть Записи (справочник по C#)
В том числе with
и солнце б утром не вставало, когда бы не было меня
Re[6]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 21.05.24 12:20
Оценка:
Здравствуйте, Serginio1, Вы писали:
S> Ну ООП это не только состояние. Но самое главное это наследование полей, свойств методов и их переопределение.
Наследование полей как раз самое неглавное. Например, в COM нет никакого наследования полей, что не мешает ему быть ОО-платформой.

S>VMT! Интерфейсы! Видимость свойств и методов.

VMT — это деталь реализации. Можно строить ООП существенно по-другому.
В том же Object Pascal (aka Delphi) есть две разных VMT.
S> Ref тоже могут быть read only readonly ref
S>Да иногда сложно читать код. Тыкаешь в метод и попадаешь либо в абстрактный либо виртуальный метод. Нужно смотреть реализацию, которая может быть у десятков и сотен классов.
Не в этом дело.
S> Вот в C# для структур нет наследования, хотя могли бы и завести тип структура с VMT как в C++
Нет смысла. Наследование структур в .Net имело бы весьма ограниченную полезность.
Наследование имеет смысл там, где можно выполнять принцип подстановки, а для этого нужна ссылка, а не экземпляр.
То есть, к примеру, не получится объявить var b = BaseStruct[] и положить в него b[0] = new DerivedStruct().
Чтобы это было можно,
а) элементы массива должны быть ссылками
б) в каждой ссылке должна быть информация о типе, чтобы GC мог правильно интерпретировать то, на что она указывает.
Получаем, собсно, reference type aka class.
Весь полиморфизм value-типов, который возможен в рамках управляемой среды, будет жить исключительно на стеке.
То есть там, где можно получить некий ref. И тогда понятно, что можно в качестве ref baseStruct передать ref DerivedStruct.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 21.05.24 13:20
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

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

В Delphi интересно сделали поддержку интерфейсов. Делали отдельную VMT для каждого объекта где перед вызовом метода корректировался Self.
В COM нет полей, но есть VMT.

S>>VMT! Интерфейсы! Видимость свойств и методов.

S>VMT — это деталь реализации. Можно строить ООП существенно по-другому.
S>В том же Object Pascal (aka Delphi) есть две разных VMT.
На самом деле одна. Просто с отрицательным смещением идет VMT для метаклассов. (class procedure DoSomething;override
Нужны ли метаклассы????1
S>> Ref тоже могут быть read only readonly ref
S>>Да иногда сложно читать код. Тыкаешь в метод и попадаешь либо в абстрактный либо виртуальный метод. Нужно смотреть реализацию, которая может быть у десятков и сотен классов.
S>Не в этом дело.
S>> Вот в C# для структур нет наследования, хотя могли бы и завести тип структура с VMT как в C++
S>Нет смысла. Наследование структур в .Net имело бы весьма ограниченную полезность.
S>Наследование имеет смысл там, где можно выполнять принцип подстановки, а для этого нужна ссылка, а не экземпляр.
S>То есть, к примеру, не получится объявить var b = BaseStruct[] и положить в него b[0] = new DerivedStruct().
S>Чтобы это было можно,
S>а) элементы массива должны быть ссылками
S>б) в каждой ссылке должна быть информация о типе, чтобы GC мог правильно интерпретировать то, на что она указывает.
S>Получаем, собсно, reference type aka class.
S>Весь полиморфизм value-типов, который возможен в рамках управляемой среды, будет жить исключительно на стеке.
S>То есть там, где можно получить некий ref. И тогда понятно, что можно в качестве ref baseStruct передать ref DerivedStruct.

Ну вот С++ прекрасно себе используют структуры и не кашляют.
Можно создать ограничения итд. А так приходится наследоваться через Агрегирование.
Кстати в том же Delphi есть Implements то есть полю делегируют реализацию интерфейса
и солнце б утром не вставало, когда бы не было меня
Отредактировано 21.05.2024 13:40 Serginio1 . Предыдущая версия .
Re[8]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.05.24 02:05
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> На самом деле одна. Просто с отрицательным смещением идет VMT для метаклассов. (class procedure DoSomething;override

https://stackoverflow.com/questions/15416733/what-is-the-difference-between-dynamic-and-virtual-methods

S> Ну вот С++ прекрасно себе используют структуры и не кашляют.

В C++ нет GC, так что обязанность отслеживать внутреннее устройство всех объектов лежит на программисте.
S>Можно создать ограничения итд. А так приходится наследоваться через Агрегирование.
S> Кстати в том же Delphi есть Implements то есть полю делегируют реализацию интерфейса
Это просто реализация COM.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 23.05.24 07:56
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:


S>> На самом деле одна. Просто с отрицательным смещением идет VMT для метаклассов. (class procedure DoSomething;override

S>https://stackoverflow.com/questions/15416733/what-is-the-difference-between-dynamic-and-virtual-methods

S>> Ну вот С++ прекрасно себе используют структуры и не кашляют.

S>В C++ нет GC, так что обязанность отслеживать внутреннее устройство всех объектов лежит на программисте.
Боксинг структуры это тот же объект. А что касается стеков и массивов, то все там хранится в явном виде.
S>>Можно создать ограничения итд. А так приходится наследоваться через Агрегирование.
S>> Кстати в том же Delphi есть Implements то есть полю делегируют реализацию интерфейса
S>Это просто реализация COM.
А что мешает это присобачить к структурам?
То есть это не интерфейс, а просто автогенерация методов, которое можно сделать через SG, а конфликты решать через атрибуты

И соответственно сделать доступ к protected полям
и солнце б утром не вставало, когда бы не было меня
Отредактировано 23.05.2024 8:06 Serginio1 . Предыдущая версия . Еще …
Отредактировано 23.05.2024 8:04 Serginio1 . Предыдущая версия .
Re[10]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.05.24 06:01
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>В C++ нет GC, так что обязанность отслеживать внутреннее устройство всех объектов лежит на программисте.

S> Боксинг структуры это тот же объект. А что касается стеков и массивов, то все там хранится в явном виде.
В том-то и дело. Как будет устроен layout массива структур в таком случае?
Будет ли массив структур ковариантен, как массив ссылочных типов?

S> А что мешает это присобачить к структурам?

Отсутствие у них VMT.
S> То есть это не интерфейс, а просто автогенерация методов, которое можно сделать через SG, а конфликты решать через атрибуты
S> И соответственно сделать доступ к protected полям
Теоретически можно это навелосипедить, но вы получите обратно reference-типы.
В чём тогда смысл "структурности"?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Базовое отличие ООП от ФП
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 24.05.24 07:22
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:


S>>>В C++ нет GC, так что обязанность отслеживать внутреннее устройство всех объектов лежит на программисте.

S>> Боксинг структуры это тот же объект. А что касается стеков и массивов, то все там хранится в явном виде.
S>В том-то и дело. Как будет устроен layout массива структур в таком случае?
S>Будет ли массив структур ковариантен, как массив ссылочных типов?

S>> А что мешает это присобачить к структурам?

S>Отсутствие у них VMT.
Еще раз наследование для структур это не VMT это наследование полей свойств и методов.
Это наследование без виртуальных методов. Для структур это запрещено!

S>> То есть это не интерфейс, а просто автогенерация методов, которое можно сделать через SG, а конфликты решать через атрибуты

S>> И соответственно сделать доступ к protected полям
S>Теоретически можно это навелосипедить, но вы получите обратно reference-типы.
S>В чём тогда смысл "структурности"?
Как я и писал выше это обычное наследование, но без виртуальных методов
и солнце б утром не вставало, когда бы не было меня
Re[12]: Базовое отличие ООП от ФП
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.05.24 03:10
Оценка:
Здравствуйте, Serginio1, Вы писали:
S>>> А что мешает это присобачить к структурам?
S>>Отсутствие у них VMT.
S> Еще раз наследование для структур это не VMT это наследование полей свойств и методов.
S>Это наследование без виртуальных методов. Для структур это запрещено!
Какой сценарий в прикладном коде выиграет от наследования с такими ограничениями?
Наследование ценно там, где экземпляр субтипа может выступать в качестве супертипа.
А в нашем случае что?
Вот у нас
public struct Name
{
  public Name: string;
}

public class Person
{
  public Name: Name;
}

А теперь мы хотим применить наследование:
public struct FullName: Name
{
  // Name: string is inherited
  public LastName: string;
}

... 
var p = new Person();
p.Name = new FullName {Name = "John", FullName = "Doe"}

Что будет происходить? Молчаливое урезание FullName до Name? Ошибка компиляции?
Единственное место, где FullName можно относительно безопасно использовать вместо Name — это ref Name аргумент в какую-нибудь функцию. Ну, или в ref-поле ref-структуры — то есть, опять же, конструкции, которая может жить исключительно на стеке.
И то, непонятно, как GC будет отслеживать ссылки — ему ведь нужно как-то понимать, что в данном экземпляре Person через Name.LastName прикопана ссылка на строку.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Отредактировано 25.05.2024 4:56 Sinclair . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.