[тип][ооп][интерфейс]Почему считается, что тип == интерфейс?

1. Ты влез в спор не с того конца.
2.

ООП - это не математика. ООП просто должно помогать в создании программ

Ты поторопился. Этот аргумент надо вытаскивать из рукава в финале плюсосрача, а не в началае терминологической притирки анонимусов.

1. Ты влез в спор не с того конца.

Что-то я уже тоже начал так же думать. :(

> Но ООП - это не математика. ООП просто должно помогать в создании программ

Динамическое ООП — да. Если мы исходим из принципа «объект — это то, что он умеет делать» и просто дергаем методы в рассчете на то, что они делают то, что нам нужно, то, последовательно проводя такую политику, мы приходим к языку типа Ruby, Smalltalk или JS. (В целом JS как инструмент говно, но сама концепция прототипного ООП — совсем не говно.)

Здесь следует понимать, что мы получаем гибкость за счёт намеренного отказа от контроля. Так, в Ruby всего один «тип» — объект. Ну а классы — просто объекты, хранящие списки методов (которые тоже объекты) и другую служебную информацию. Ни к классам Си++, ни к тип-классам хаскеля такие классы не имеют отношения вообще.

Теперь рассмотрим другой подход. Разделим весь «мир» предметной области на четко очерченные понятия и опишем эти понятия на языке. Дадим машине возможность контроллировать систему понятий-абстракций и бить нас по рукам, если мы что-нибудь попытаемся сделать не так. Это именно что «обязательно должно обладать свойствами «строгой непротиворечивости»». И тут у нас есть два (как минимум) варианта развития этой идеи — 1) статическое ООП в идеологических потомках Симулы, 2) система типов и классов хаскеля. Первая костыльная, вторая мощная и выразительная.

Статическое ООП в реальных проектах вырождается в полную херню и постоянный рефакторинг. В зависимости от задачи, предпочтительнее использовать либо грамотное динамическое ООП, либо статически-типизированные языки, имеющие более мощную систему типов, чем СООП.

Вот и всё.

> Почему считается, что тип объекта — его интерфейс?

Потому что это позволяет развести срач ни о чём на ровном месте.

> Притом, что ООП - это хороший способ выстроить и упорядочить систему абстракций.

ООП - это не способ построения системы абстракций. ООП - это способ смотреть на модель программы, как на совокупность объектов, которые взаимодействуют друг с другом путем пересылки сообщений. Причем нам не важно как и в каком стиле программа написана, _любая_ программа - ООП, так как мы можем смотреть на нее с точки зрения ООП.

Роль у ООП сугубо «низменно прикладная», а не «высокодуховная теоретическая».

Просто ты не знаешь ООП (точнее не ООП, а то, что ты под ним понимаешь - то есть все эти классы и интерфейсы).

> Статическое ООП в реальных проектах вырождается в полную херню и постоянный рефакторинг. В зависимости от задачи, предпочтительнее использовать либо грамотное динамическое ООП, либо статически-типизированные языки, имеющие более мощную систему типов, чем СООП.

Всё это звучит отлично. Но почему-то в теории. На практике «имеющие более мощную систему типов» языки не осилили ничего сложнее xmonad'а (ок, еще - ml-donkey). И мне страшно подумать, во что выльется рефакторинг решений на них, если этими инструментами решать «real world» задачи.

> Это тащемта проблемы программиста, а не языка.

Ну разумеется. Всегда, когда приходится лепить в языке костыли, говорится, что «это проблема программиста». Например: «в сишке нету GC! перекладывание байтиков и сегфолты» - «это проблемы программиста». А вот в каком-нибудь сишарпе у меня нету никаких таких проблем, я могу хоть тыщу интерфейсов определить с одинаковыми сигнатурами, но они будут называться по-разному и не будут одним типом. Если нечто является «проблемой программиста» в одном ЯП, но не является таковой в другом (по причине отсутствия) - то это и называется «проблемой языка».

Таки да. Экономически эффективнее, наверное, нанять 100 выпускников «со знанием C#» и менять их по необходимости. Т.е. проблема в общем-то не в языке как средстве для выражения абстракций и алгоритмов, а в языке как инструменте, чьи применение требует определённых затрат.

В хаскеле нет ООП

ad-hoc полиморфизм там есть, инкапсуляция тоже; нет extensible records, ну да они для ООП не так уж и критичны, как по мне

классы и интерфейсы никак не связаны с ООП

да, лучший ООП язык - это Erlang. ну и Smalltalk

А что будет, если я в хаскеле определю два разных тайпкласса, в которых будет ф-я с одинаковым именем, а потом попробую инстанцировать оба этих тайпкласса для одного типа?

плохо будет

> либо статически-типизированные языки, имеющие более мощную систему типов, чем СООП.

Это , конечно, хорошо, но таких пока не придумали.

> ad-hoc полиморфизм там есть, инкапсуляция тоже; нет extensible records, ну да они для ООП не так уж и критичны, как по мне

Но, повторю вопрос - при чем тут ООП?

да, лучший ООП язык - это Erlang. ну и Smalltalk

Именно так.

Вот именно. Спасибо, но ваша система типов - говно.

> Например: «в сишке нету GC!

Зато к нему можно подключить внешний GC. Это во-первых. Во-вторых, а что вы хотели от переносимого ассемблера? Это не баг, а необходимая фича языка.

перекладывание байтиков и сегфолты» - «это проблемы программиста»

Это проблемы производительности. Не пишите без необходимости на Си. Пишите на Си только то, что невозможно реализовать другими инструментами из-за недостаточной производительности результата.

А вот в каком-нибудь сишарпе у меня нету никаких таких проблем, я могу хоть тыщу интерфейсов определить с одинаковыми сигнатурами, но они будут называться по-разному и не будут одним типом.

Ну и зачем так делать?

> Ну и зачем так делать?

Это естественный способ. Почему я должен думать над тем, что у меня метод некоторого интерфейса совпадает с методом некоторого другого, который может быть определен вообще хрен знает где в сторонней либе?

>не осилили ничего сложнее xmonad'а (ок, еще - ml-donkey)
А как же Coq?

>перекладывание байтиков и сегфолты

Сегфолты или необработанные исключения - какая разница из-за чего падать?

Если нечто является «проблемой программиста» в одном ЯП, но не является таковой в другом (по причине отсутствия) - то это и называется «проблемой языка».

Ну, сделай нативный код на шарпе.

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

И как ты собрался вызывать методы с совпадающими именами, если объект реализует оба этих интерфейса?

Вот именно. Спасибо, но ваша система типов - говно.

предложи лучше :)

А вот в каком-нибудь сишарпе у меня нету никаких таких проблем, я могу хоть тыщу интерфейсов определить с одинаковыми сигнатурами, но они будут называться по-разному и не будут одним типом

зато в C# (равно как и в C++) ты не можешь сделать класс типов Monad. слабенькая, слабенькая система типов в C#, при всех его достоинствах

> И как ты собрался вызывать методы с совпадающими именами, если объект реализует оба этих интерфейса?

Привести тип и вызвать. Но на самом деле, кто тебе сказал, что все эти интерфейсы будут реализованы вместе?

> ты не можешь сделать класс типов Monad.

Ну, вобщем-то могу, только диспатч будет в рантайме.

А что с ним? С его помощью уже можно скачать по сети пару файлов? Проиграть музыку? Сделать видеозвонок на деревню дедушке? Обработать миллионы записей? Отрендерить туеву хучу полигонов в секунду или, прости господи, раздать по сети веб-странички?

Короче говоря, какое отношение он имеет к «real world» задачам?

> Короче говоря, какое отношение он имеет к «real world» задачам?

не меньшее, чем хаскель.

Привести тип и вызвать.

Охщи. И чем это отличается от:

vadim@host3:~$ grep '' m?.hs
m1.hs:module Main where
m1.hs:
m1.hs:  import M2
m1.hs:  import M3
m1.hs:
m1.hs:  data T1 = T1 {t1Id :: String}
m1.hs:
m1.hs:  instance C2 T1 where
m1.hs:	name a = "'" ++ t1Id a ++ "'"
m1.hs:
m1.hs:  instance C3 T1 where
m1.hs:	name a = "\"" ++ t1Id a ++ "\""
m1.hs:
m1.hs:
m1.hs:  main = putStrLn $ M2.name (T1 "bla") ++ M3.name (T1 "bla")
m2.hs:module M2 where
m2.hs:
m2.hs:  class C2 a where
m2.hs:    name :: a -> String
m3.hs:module M3 where
m3.hs:
m3.hs:  class C3 a where
m3.hs:    name :: a -> String
vadim@host3:~$ ghc -o m1 m?.hs && ./m1
[3 of 3] Compiling Main             ( m1.hs, m1.o )
Linking m1 ...
'bla'"bla"

Т.е. ты тоже считаешь, что никакого? ))

> Ну, вобщем-то могу, только диспатч будет в рантайме.

Т.е. статическая система типов зафейлилась на такой задаче? Что и требовалось доказать.

Когда уже все эти одепты функцыональщины узают про ООП на мультиметодах и обобщенных функциях?

Когда уже все эти одепты функцыональщины узают про ООП на мультиметодах и обобщенных функциях?

я знаю. что дальше?

Coq написан на OCaml. И уж поверь он сильно сложней xmonad и mldonkey. Но по твоему потоку сознания ясно, что ты вообще не в курсе что за Coq.

Какая разница, на чем он написан, если он в любом случае не имеет отношения к разговору?

ты вообще не в курсе что за Coq

Гугл сообщил мне, что это инструмент верификации. Он нагло лжёт?

> предложи лучше :)

Раз нормальных систем типов пока не создали - лучше ими вообще не пользоваться.

> Охщи. И чем это отличается от:

При чем тут вообще это? Мы же говорим о случае, когда «одинаковые» интерфейсы реализуют разные объекты, а не один и тот же. Ну и в любом случае даже так - разница в том, что не будет костыльного говна с модулями.

Именно.

>Какая разница, на чем он написан, если он в любом случае не имеет отношения к разговору?

Это не твоя фраза: " На практике «имеющие более мощную систему типов» языки не осилили ничего сложнее xmonad'а (ок, еще - ml-donkey)."? Я тебе показал пример сложного реального и работающего инструмента, написанного на языке имеющего более мощную систему типов.

Гугл сообщил мне, что это инструмент верификации. Он нагло лжёт?

И не только для верификации.

> Т.е. статическая система типов зафейлилась на такой задаче?

Почему же зафейлилась? Ничуть не зафейлилась, просто в «ООП» принятно диспатч по реализации интерфейса проводить именно в рантайме. Для гибкости. В данном случае IMonad<T> - это интерфейс, а конкретные монады - это его реализации. Вобщем-то, практически все, что есть в хаскеле, довольно-таки просто переносится.

Раз нормальных систем типов пока не создали - лучше ими вообще не пользоваться.

у трактора много недостатков - ты предлагаешь пахать плугом? лопатой? руками?

Вобщем-то, практически все, что есть в хаскеле, довольно-таки просто переносится

практически, да не всё

> у трактора много недостатков - ты предлагаешь пахать плугом? лопатой? руками?

Нет, я в данном случае просто предлагаю выбрать трактор другой фирмы, который этих недостатков лишен.

Мы же говорим о случае, когда «одинаковые» интерфейсы реализуют разные объекты, а не один и тот же.

О чем ты вообще? Может ты не знаешь, что такое классы хаскеля?

Ок, специально для тебя:

module Main where

  import M2
  import M3

  data T1 = T1 {t1Id :: String}
  data T2 = T2

  instance C2 T1 where
	name a = "'" ++ t1Id a ++ "'"

  instance C3 T1 where
	name a = "\"" ++ t1Id a ++ "\""

  instance C2 T2 where
	name a = "blablabla"

  instance C3 T2 where
	name a = "bazbazbaz"


  main = putStrLn $ M2.name (T1 "bla") ++ M3.name (T1 "bla") ++ M2.name T2 ++ M3.name T2

Ну вот, прекрасно все реализовано, в чем проблема?

> О чем ты вообще?

Я о следующем. Есть два интерфейса с «одинаковыми» сигнатурами и есть два класса, первый класс реализует только первый интерфейс, второй класс - только второй. В «ООП» никаких проблем с этим не будет, просто реализуешь и потом свободно вызываешь методы интерфейсов. На тайпклассах хаскеля такое выразить в принципе невозможно, что ты и доказал - тебе пришлось водить дополнительные конструкции в виде модулей для решения этой задачи. + приходится через модули вызывать ф-и, чего в «ООП» не надо будет. Короче - кривой костыль, как и все в хаскеле.

>> Это не твоя фраза: " На практике «имеющие более мощную систему типов» языки не осилили ничего сложнее xmonad'а (ок, еще - ml-donkey)."?

Я тебе показал пример сложного реального и работающего инструмента

А «real world» ты куда выкинул? Или для тебя «реальный мир» - это «в принципе существует, и работает на трех с половиной компьютерах»?

Ну вот, прекрасно все реализовано, в чем проблема?

ну кому прекрасно, кому костыли

Ну а чего ты хотел? Как выше было замечено, «в хаскеле нет ООП», и тип данных не образует собственного пространства имён. Эта проблема вообще лежит в отдельной от системы классов хаскеля плоскости. Ты бы еще к Си предъявил претензии относительно невозможности использовать в нём пространства имён.

На тайпклассах хаскеля такое выразить в принципе невозможно

На тайпклассах и не нужно выражать синтаксис сишарпа, это нелепо. В хаскеле ты не вызываешь метод объекта, а наоборот — вызываешь функцию интерфейса (класса), применимую к данному типу.

> На тайпклассах и не нужно выражать синтаксис сишарпа, это нелепо.

При чем тут _синтаксис_ сишарпа?

В хаскеле ты не вызываешь метод объекта, а наоборот — вызываешь функцию интерфейса (класса), применимую к данному типу.

Это-то при чем? У нас есть две системы, которые позволяют использовать интерфейсы. Система шарпа позволяет определять интерфейсы с пересекающимися сигнатурами, система хаскеля - нет. система хаскеля более бедна. Все. По каким причинам она более бедна - это меня уже не волнует, это проблема разработчиков хаскеля, которые сделали глупость.

Если классы в одном модуле - то компилятор будет ругаться. Если в разных - то наздоровье, механизм работы с одноименными функциями из разных модулей есть.

Ну я и говорю - приходится использовать дополнительную конструкцию, сами тайпклассы так не умеют.

>Почему считается, что тип объекта — его интерфейс?

О! Оказывается такие бредовые идеи возникают не только у меня...

И не просто тип == интерфейс, а класс == тип == интерфейс == поведение. И еще принудительное наследование типа и интерфейса. Мне это тоже не понятно.

>тебе пришлось водить дополнительные конструкции в виде модулей для решения этой задачи

Вот до чего довели современных программистов. Для них модули --- «дополнительные» конструкции. Как же страшно жить.