Информация об изменениях

Сообщение Re[13]: Базовое отличие ООП от ФП от 27.05.2024 7:46

Изменено 27.05.2024 7:54 Serginio1

Re[13]: Базовое отличие ООП от ФП
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:
S>>>> А что мешает это присобачить к структурам?
S>>>Отсутствие у них VMT.
S>> Еще раз наследование для структур это не VMT это наследование полей свойств и методов.
S>>Это наследование без виртуальных методов. Для структур это запрещено!
S>Какой сценарий в прикладном коде выиграет от наследования с такими ограничениями?
S>Наследование ценно там, где экземпляр субтипа может выступать в качестве супертипа.
S>А в нашем случае что?
S>Вот у нас
S>
S>public struct Name
S>{
S>  public Name: string;
S>}

S>public class Person
S>{
S>  public Name: Name;
S>}
S>

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

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

S>Что будет происходить? Молчаливое урезание FullName до Name? Ошибка компиляции?
S>Единственное место, где FullName можно относительно безопасно использовать вместо Name — это ref Name аргумент в какую-нибудь функцию. Ну, или в ref-поле ref-структуры — то есть, опять же, конструкции, которая может жить исключительно на стеке.
S>И то, непонятно, как GC будет отслеживать ссылки — ему ведь нужно как-то понимать, что в данном экземпляре Person через Name.LastName прикопана ссылка на строку.


Для структур такое присвоение запрещено, как и ref.
p.Name = new FullName {Name = "John", FullName = "Doe"}


В чем проблемы? Мы работаем не с объектами!

В конце концов это может быть SG с доступом к protected полям и свойствам!
Re[13]: Базовое отличие ООП от ФП
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:
S>>>> А что мешает это присобачить к структурам?
S>>>Отсутствие у них VMT.
S>> Еще раз наследование для структур это не VMT это наследование полей свойств и методов.
S>>Это наследование без виртуальных методов. Для структур это запрещено!
S>Какой сценарий в прикладном коде выиграет от наследования с такими ограничениями?
S>Наследование ценно там, где экземпляр субтипа может выступать в качестве супертипа.
S>А в нашем случае что?
S>Вот у нас
S>
S>public struct Name
S>{
S>  public Name: string;
S>}

S>public class Person
S>{
S>  public Name: Name;
S>}
S>

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

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

S>Что будет происходить? Молчаливое урезание FullName до Name? Ошибка компиляции?
S>Единственное место, где FullName можно относительно безопасно использовать вместо Name — это ref Name аргумент в какую-нибудь функцию. Ну, или в ref-поле ref-структуры — то есть, опять же, конструкции, которая может жить исключительно на стеке.
S>И то, непонятно, как GC будет отслеживать ссылки — ему ведь нужно как-то понимать, что в данном экземпляре Person через Name.LastName прикопана ссылка на строку.


Для структур такое присвоение запрещено, как и ref.
p.Name = new FullName {Name = "John", FullName = "Doe"}


В чем проблемы? Мы работаем не с объектами!

В конце концов это может быть агрегирование с SG с доступом к protected полям и свойствам!