Здравствуйте, 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 полям и свойствам!

Здравствуйте, Разраб, Вы писали:

Многие концепции в ООП и ФП сходны, особенно это видно на гибридных (а не чистых функциональных) языках. Замыкание создает объект с полями, алгебраические типы и pattern matching напоминают наследование и т.д.
OCaml, Haskell, CLOS в Common Lisp так или иначе добавляют ООП к функциональной парадигме. Ключевым является только вопрос изменяемого состояния у объектов, и вот он решается по-разному.
Теория категорий, на которой базируется Haskell, определяет категорию как набор доменов (данных) и морфизмов (стрелок, связей, функций) между ними — это похоже на определение ООП по Алану Кею (существуют только объекты и сообщения между ними + скрытие состояния и познее связывание).
Я сейчас как раз пытаюсь самостоятельно реализовать ООП на Лиспе через замыкания и setq, но пока выходит криво и неудобно. Хотелось бы что-то вроде:

((MessageDialog "Hello World!") 'show)

(let
  (
    (hero (Sprite (Image "gfx/hero.png")))
  )
  (hero 'moveTo 320 240)
)

(let
  (
    (mainWindow (Window "App" 640 480 1 2))
  )
  (let
    (
      (helloLabel (Label mainWindow "Hello World!" '(0 0)))
      (exitButton (Button
        mainWindow
        "Exit"
        '(1 0)
        '(
           '('onClick (lambda (sender) (mainWindow 'close)))
         )
      ))
    )
    (mainWindow 'show)
  )
)

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

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

S>Принципиальное отличие в наличии изменяемого состояния, для которого необходима идентифицируемость (identity).

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

Здравствуйте, mrTwister, Вы писали:
T>Имхо, неизменяемого состояния не достаточно. В ФП не менее важно, что данные являются самодостаточными, они не привязаны к методам. То есть функции отдельно, данные отдельно. Это сильно меняет способ декомпозиции. ФП программа выглядит иначе — обычно это пайплайн из функций, через который "прокачиваются" данные. Если сделать обычные классы, у которыйх все поля readonly — это все равно ООП программа. ФП появляется, когда есть пайплайн.
Ну, во-первых, если вы попробуете написать программу с "обычными классами, у которых все поля readonly", а также константами вместо всех локальных переменных, то вы неизбежно получите пайплайн (как мне кажется).
Во-вторых, для практического программирования иммутабельности, конечно же, недостаточно.
Например потому, что эмуляция ФП в виде readonly-классов заставит вручную выписывать все замыкания, что сделает код утомительно многословным.

Здравствуйте, Worminator X, Вы писали:
WX>Я сейчас как раз пытаюсь самостоятельно реализовать ООП на Лиспе через замыкания и setq, но пока выходит криво и неудобно. Хотелось бы что-то вроде:
У нас в магистратуре в курсе лекций по Clojure кратко упоминалась возможность навелосипедить себе какое угодно ООП. С наследованием хоть интерфейсов, хоть реализации, хоть состояния.
С прототипным наследованием и с наследованием классов. С одиночным и множественным наследованием. С одинарной, двойной, и множественной диспетчеризацией.
Один из предлагаемых курсовиков, ЕМНИП, как раз был "реализуйте свой вариант ООП". Поскольку у лиспа синтаксиса никакого нет, то любой результат будет не хуже встроенных лисп-конструкций.
Подробностей я, к сожалению, не запомнил, но могу взять копию слайдов у лектора

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

S>Ну, во-первых, если вы попробуете написать программу с "обычными классами, у которых все поля readonly", а также константами вместо всех локальных переменных, то вы неизбежно получите пайплайн (как мне кажется).

Не получится пайплайн, так как функции не будут друг другом стыковаться. Чтобы стыковались, надо отделять данные от функций, как в линке, где есть отдельно IEnumerable и отдельно набор extension методов над ним. ФП — это когда вся программа подобным образом устроена. При этом сильно меняется подход к декомпозиции. Забавно смотреть, когда берут обычный ООП код, внутри метода какого-нибудь класса используют паттерн-матчинг и думают, что это теперь такой ФП