gds (gds) wrote,
gds
gds

краткая характеристика ООП в окамле

Отвечал на этот комментарий в жыжыцэ ребе metaclass, решил вытащить в отдельный птсо, может кому понадобится.

Вот тут -- Private row types: abstracting the unnamed -- описываются применения row types (и полиморфных вариантных типов заодно).
Если вкратце и своими словами, типизация объектов в окамле структурная (член структуры = метод = "row" в официальной терминологии). Обращение к члену структуры (obj#meth) заставляет тайпчекер статически гарантировать наличие у объекта obj метода meth.
Нет номинальной типизации/подтипизации объектов (по имени класса), но она легко эмулируется, если нужна.
Поля объектов могут быть как изменяемыми, так и неизменными, по желанию. Поля видны только в пределах объекта, методы видны и в пределах объекта, и за пределами. Класс может иметь типы-параметры (как обычные параметрические типы). Методы класса могут быть полиморфными (через это имеем полиморфизм второго ранга в объектах). Существует возможность создать объект или описать объектный тип, не создавая класс. Поддерживаются виртуальные методы (и статически проверяется, что любой создаваемый объект должен иметь полностью определённые методы). Поддерживается множественное наследование (хотя даже обычное наследование не часто нужно).
Одно из классных свойств ООП в окамле состоит в том, что нет нужды использовать большинство ООП-паттернов. А вот для чего можно использовать ООП, так это для эмуляции duck typing и typeclasses.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 5 comments
А нарисуй мне комонаду в виде окамлевого кода? ;-)
какой вопрос -- такой ответ :)
module type COMONAD =
  sig
    type c 'a;
    value counit : c 'a -> 'a;
    value cobind : (c 'a -> 'b) -> c 'a -> c 'b;
  end
;

А всё потому, что комонада в общем виде -- нечто абстрактное, отвечающее каким-то правилам, и без конкретики не будет никакой реализации. Максимум -- её сигнатура (отражающая часть правил).
Что-то не соображу, а как сделать
требование наследования, навроде
class CoMonad a => MyType a where
шурум-бурум
то наследование, которое в ООП, отличается от наследования в typeclass'ах.
Далее, в окамловских классах нет возможности создать параметрический тип, зависящий от параметра класса (то есть, я не могу указать, что хочу передать в класс параметрический тип "list" и сказать, чтобы в классе были типы вида "list 'a"). Собственно, классические ограничения ML, мешающие передать вместо типа "c" какой-нибудь другой тип, из которого создавать "c 'a".
Если же делать через наследование, уткнёмся в тип cobind -- из-за наследования не получается сделать рекурсивную отсылку на себя же, но с другим типовым параметром (помним, там надо "c 'a" и "c 'b" одновременно), какие-то детали тайпчекера.
На практике комонады не нужны, хватает коиндуктивного Stream и, опционально, подобных ему структур данных.
Разумеется, наследование отличается.
Просто ты сказал про эмуляцию классов типов.
В общем, мне с этим всё понятно.
Надо ещё про функторы вспомнить...
Помнится, давно ещё, смотрел, что можно
делать ML-функторами, и мне это понравилось.