Здравствуйте, PSV100
PSV>Лично я двумя руками за упрощение. Я не вижу никакого кайфа в иерархии интерфейсов, как таковой. И война с ограничениями системы типов пусть останется для Хаскеля, это его стихия. Проблема в том, что действительно иногда необходимо где-то выразить сущность типа именно как "объединение" (INum IFractional). Имхо, в языках с динамической типизацией, как та же Кложура, возможно, это не так восстребовано. А для Ela есть идеи как указать такие "объединения" ? (сорри, если глупость спрашиваю, я с языком знакомился уже давненько и "по диагонали", и недавно видел здесь инфу про появление "протоколов")
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я не понимаю, зачем мне приводить интерфейсы, и как это помогает полиморфизму. Моему коду нужен ICollection.
Но я могу мой экземпляр ICollection передать в любой алгоритм, работающий с IEnumerable.
По-моему, это удобно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Я не понимаю, зачем мне приводить интерфейсы, и как это помогает полиморфизму. S>Моему коду нужен ICollection. S>Но я могу мой экземпляр ICollection передать в любой алгоритм, работающий с IEnumerable.
В таком случае вашему коду нужен не ICollection, а "ICollection+IEnumerable", раз внутри него вызывается нечто, требующее IEnumerable.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, SV., Вы писали:
ВВ>>>Я не знаю, что именно отражает ваш код, и какие именно мессенджеры существуют в жизни — а вы же по ходу уверены, что точно и наверняка знаете какие абстракции будут правильны в 100% случаев. Вот только в 100% эти абстракции оказываются неправильными. SV.>>Это бывает, да. Но для того и меню Refactor, чтобы в момент осознания несогласованности вашей объектной модели с жизнью его нажимать. И если не лениться и рефакторить код каждый раз, когда это вылезает, то да, НА ПРАКТИКЕ в 100% случаев ваши абстракции будут, как вы выразились, "правильными" (я же имел в виду их неискуственность => удобочитаемость => поддерживаемость).
Можно обобщить — есть набор базовых действий которые могут совершать некоторые сущности, к примеру те же мессенджеры, пример:
1. отправить текст
2. отправить файл
3. установить статус пользователя
N. ... etc.
есть конкретный мессенджер, который может выполнять определенный набор действий, например скайп. Его тоже имеет смысл описать через интерфейс — исключительно для удобства потенциальных клиентов в то же время скрыв детали реализации.
Иными словами SkypeMessenger должен быть интерфейсом, реализующим набор базовых интерфейсов-действий из 1..N (для облегчения тестирования моками, для снижения связности, для простоты наконец для конечных потребителей этого класса).
Используя IoC контейнер можно ссылаться на SkypeMessenger как на несколько раздельных интерфейсов внедренных как зависимости в некоторый класс, но я не вижу никаких преимуществ у такого решения.
Здравствуйте, Воронков Василий, Вы писали:
AVK>>Меня интересует, что будет взамен наследования контрактов, т.е. какой механизм динамической диспетчеризации в языке будет основным, и что взамен наследования реализаций, т.е. как реиспользовать готовые реализации контрактов?
ВВ>Ну т.е. наследование нужно для подключения реализации?
В том числе.
ВВ> Неужели это без наследования никак не сделать?
Вообще можно, в существующих мейнстрим языках только ценой большего количества писанины.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, AlexRK, Вы писали:
ARK>Для динамической диспетчеризации достаточно только концепции интерфейса, зачем здесь наследование? ARK> Интерфейс и несколько реализаций — классов. Или я чего-то не понял?
. А реализация интерфейса это тоже наследование контракта по сути, только с двойной косвенностью и без наследования реализации.
AVK>>Это не решает проблемы динамической диспетчеризации никак.
ARK>Почему не решает?
Потому что все равно нужно наследование или другой какой то механизм. Например алгебраические типы данных ака discriminated unions + РМ. Или мультиметоды. Ты же предлагаешь наследование запретить, а вот что в замен не говоришь.
ARK> Поясните мысль или приведите пример. Википедия, к слову, со мной согласна (http://en.wikipedia.org/wiki/Dynamic_dispatch) — про наследование в статье ни слова.
Второй абзац:
This Object-Oriented feature allows substituting a particular implementation using the same interface, and therefore it enables polymorphism.
В мейнстриме такой механизм называется наследованием (для интерфейсов — реализацией). Статья просто очень обобщенная, описывающая сам принцип, а не конкретные механизмы реализации.
Мне вот интересно — ты действительно считаешь, что наследование не имеет отношения к динамической диспетчеризации, или это прием спора такой?
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, AlexRK, Вы писали:
ARK>>Для динамической диспетчеризации достаточно только концепции интерфейса, зачем здесь наследование? ARK>> Интерфейс и несколько реализаций — классов. Или я чего-то не понял?
AVK>Зачем наследование интерфейсов между собой я ответил в Re[7]: Зачем нужно наследование интерфейсов?
. А реализация интерфейса это тоже наследование контракта по сути, только с двойной косвенностью и без наследования реализации.
Хм... Не вижу в том ответе обоснования необходимости наследования.
Заменяем "выносишь общую часть разных интерфейсов в одного предка" на "выносишь общую часть разных интерфейсов в один отдельный интерфейс" — все остальное то же самое.
"с наследованием просто писанины меньше, перечислять всю потребную кучу интерфейсов в большой иерархии может быть накладно" — это вопрос синтаксиса, наверное можно сделать что-то типа alias'ов. Перечислять тонну хлама в генериках тоже ведь накладно.
Третий пункт, честно, не очень понял. Что именно наследование задает, повышает и накладывает. Зачем IButton должен быть отнаследован от IControl? Хотелось бы реальный пример.
AVK>>>Это не решает проблемы динамической диспетчеризации никак.
ARK>>Почему не решает?
AVK>Потому что все равно нужно наследование или другой какой то механизм. Например алгебраические типы данных ака discriminated unions + РМ. Или мультиметоды. Ты же предлагаешь наследование запретить, а вот что в замен не говоришь.
Полиморфизм нужен. Алгебраические типы — неплохо. А зачем нужно наследование и зачем его заменять — пока не могу найти мотивов.
ARK>> Поясните мысль или приведите пример. Википедия, к слову, со мной согласна (http://en.wikipedia.org/wiki/Dynamic_dispatch) — про наследование в статье ни слова.
AVK>Второй абзац: AVK>
AVK>This Object-Oriented feature allows substituting a particular implementation using the same interface, and therefore it enables polymorphism.
AVK>В мейнстриме такой механизм называется наследованием (для интерфейсов — реализацией). Статья просто очень обобщенная, описывающая сам принцип, а не конкретные механизмы реализации.
Ага.
AVK>Мне вот интересно — ты действительно считаешь, что наследование не имеет отношения к динамической диспетчеризации, или это прием спора такой?
Наследование безусловно имеет отношение к динамической диспетчеризации. Это одна из форм динамической диспетчеризации. Но не единственная и, более того, по моему мнению, не нужная. В Haskell динамическая диспетчеризация есть, а наследования нет.
P.S. Никакие "приемы спора" я не использую, во всяком случае сознательно.
ВВ>То, что вы хотите описать в рамках системы типов шарпа вообще не описывается. Потому что на самом деле та же проекция должна выглядеть так: C<E2> Map<C,E1,E2>(C<E1> seq, Func<E1,E2> fun)
не всякое C сохраняется при mapping-е. Например, упорядоченность не сохраняется.
Соответственно, для iorderedenumerable map будет другим. И такие сложные взаимосвязи едва ли можно выразить синтаксисом сильно отличающимся от перегрузки.
. А реализация интерфейса это тоже наследование контракта по сути, только с двойной косвенностью и без наследования реализации.
Да ты не ответил. Собственно, все, что здесь пишут отнаследовании интерфейсов, говорит лишь о том, что нужно не наследование, а возможность описывать тип в виде набора интерфейсов.
AVK>>>Это не решает проблемы динамической диспетчеризации никак. ARK>>Почему не решает? AVK>Потому что все равно нужно наследование или другой какой то механизм. Например алгебраические типы данных ака discriminated unions + РМ. Или мультиметоды. Ты же предлагаешь наследование запретить, а вот что в замен не говоришь.
Не понимаю, честно говоря, какое отношение АлгТД имеют к динамик диспатчу.
AVK>Второй абзац: AVK>
AVK>This Object-Oriented feature allows substituting a particular implementation using the same interface, and therefore it enables polymorphism.
AVK>В мейнстриме такой механизм называется наследованием (для интерфейсов — реализацией). Статья просто очень обобщенная, описывающая сам принцип, а не конкретные механизмы реализации. AVK>Мне вот интересно — ты действительно считаешь, что наследование не имеет отношения к динамической диспетчеризации, или это прием спора такой?
А ты правда считаешь, что динамик диспатч возможен только при наследовании? Достаточно утиной типизации вообще-то.
Кстати, приведенная цитата из википедии, мне кажется, не совсем корректна, так как сужает ООП до лишь одного его вида. А вообще еще и протипы есть.
Здравствуйте, AlexRK, Вы писали:
ARK>Наследование безусловно имеет отношение к динамической диспетчеризации. Это одна из форм динамической диспетчеризации. Но не единственная и, более того, по моему мнению, не нужная. В Haskell динамическая диспетчеризация есть, а наследования нет.
Ну вообще, если оставить за скобками те же экзистенциалы и полиморфную рекурсию, то в Хаскелле получается как раз наоборот — наследование есть, а динамик диспатча нет.
Здравствуйте, AlexRK, Вы писали:
ARK>Хм... Не вижу в том ответе обоснования необходимости наследования.
А я не говорил что наследование необходимо. Необходимо средство динамической диспетчеризации.
ARK>Заменяем "выносишь общую часть разных интерфейсов в одного предка" на "выносишь общую часть разных интерфейсов в один отдельный интерфейс" — все остальное то же самое.
Там по ссылке есть ответ, в чем разница. И, на всякий случай — реализация интерфейса в классе это тоже наследование контракта. Интерфейсы, как я понимаю, ты отменять не собираешься, значит и наследование как таковое никуда не девается. Т.е. те же яйца, вид в профиль.
ARK>это вопрос синтаксиса, наверное можно сделать что-то типа alias'ов.
А зачем? Наследование интерфейсов прекрасно эту задачу решает.
ARK> Перечислять тонну хлама в генериках тоже ведь накладно.
Ну вот пока не приходится тонну хлама перечислять.
ARK>Третий пункт, честно, не очень понял. Что именно наследование задает, повышает и накладывает. Зачем IButton должен быть отнаследован от IControl?
Семантика такая. Я интерфейс IButton проектирую из рассчета, что это контрол. Наследование позволяет этот мой рассчет зафиксировать явно, с проверкой компилятором.
ARK>Полиморфизм нужен. Алгебраические типы — неплохо. А зачем нужно наследование
Затем же, зачем и алгебраические типы.
AVK>>Мне вот интересно — ты действительно считаешь, что наследование не имеет отношения к динамической диспетчеризации, или это прием спора такой?
ARK>Наследование безусловно имеет отношение к динамической диспетчеризации.
Уже хорошо. Тогда поясни, к чему фраза про то, что в викишной статье про наследование ни слова?
ARK> Это одна из форм динамической диспетчеризации. Но не единственная
А что, кто то утверждал что единственная?
ARK> и, более того, по моему мнению, не нужная
Отлично, что взамен?
ARK>. В Haskell динамическая диспетчеризация есть, а наследования нет.
В Хаскеле есть ФВП и нет классов и 100% кода построено на этих ФВП. Естественно, наследование там не нужно, да и неприменимо.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Да ты не ответил.
Ответил. И оценки говорят, что, как минимум, еще 3 человека считают так же. То что ответ тебе не нравится — я тут не виноват.
ВВ>Не понимаю, честно говоря, какое отношение АлгТД имеют к динамик диспатчу.
Прямое. Единственный их смысл — применение в комплекте с PM (сами по себе, без РМ, это малополезный артефакт). А РМ по АлгТД решает именно что задачу динамической диспетчеризации.
ВВ>А ты правда считаешь, что динамик диспатч возможен только при наследовании?
Попробуй привести цитату, где я подобное утверждаю.
ВВ> Достаточно утиной типизации вообще-то.
AlexRK ничего про нее не писал.
ВВ>Кстати, приведенная цитата из википедии, мне кажется, не совсем корректна, так как сужает ООП до лишь одного его вида. А вообще еще и протипы есть.
Приведенная фраза прекрасно подходит и прототипному ОО. И именно из-за прототипного ОО в ней нет слова inheritance.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну вообще, если оставить за скобками те же экзистенциалы и полиморфную рекурсию, то в Хаскелле получается как раз наоборот — наследование есть, а динамик диспатча нет.
Динамическая диспетчеризация есть в любом языке с ФВП.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, AlexRK, Вы писали:
ARK>>Наследование безусловно имеет отношение к динамической диспетчеризации. Это одна из форм динамической диспетчеризации. Но не единственная и, более того, по моему мнению, не нужная. В Haskell динамическая диспетчеризация есть, а наследования нет.
ВВ>Ну вообще, если оставить за скобками те же экзистенциалы и полиморфную рекурсию, то в Хаскелле получается как раз наоборот — наследование есть, а динамик диспатча нет.
Ээ... а классы типов это не динамик диспатч? Я не большой спец в Хаскелле, мне казалось, что там нельзя один класс типов отнаследовать от другого.
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Ну вообще, если оставить за скобками те же экзистенциалы и полиморфную рекурсию, то в Хаскелле получается как раз наоборот — наследование есть, а динамик диспатча нет. AVK>Динамическая диспетчеризация есть в любом языке с ФВП.
Ну речь же про наследование. И тайпклассы, с рядом оговорок, это не динамик диспатч.
А с ФВП ты сам прекрасно ответил на вопрос, как же возможен динамик диспатч без наследования. Что, кстати, уже начинает наводить на подозрения
Здравствуйте, AlexRK, Вы писали:
ВВ>>Ну вообще, если оставить за скобками те же экзистенциалы и полиморфную рекурсию, то в Хаскелле получается как раз наоборот — наследование есть, а динамик диспатча нет. ARK>Ээ... а классы типов это не динамик диспатч? Я не большой спец в Хаскелле, мне казалось, что там нельзя один класс типов отнаследовать от другого.
Instance selection — статический. А наследование там есть. Вообще тему, конечно, стоило про Хаскелл создать.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну речь же про наследование.
Речь про отмену наследования.
ВВ> И тайпклассы, с рядом оговорок, это не динамик диспатч.
Т.е ты сам придумал, что тайпклассы это ДД, и сам же с блеском опровергнул?
ВВ>А с ФВП ты сам прекрасно ответил на вопрос, как же возможен динамик диспатч без наследования.
А такого вопроса никто не задавал. Вопрос был к AlexRK, как он предполагает реализовывать ДД.
ВВ> Что, кстати, уже начинает наводить на подозрения
Ага, на то, что кто то толи не читает топик, толи не понимает смысл прочитанного.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, AlexRK, Вы писали:
ARK>>Хм... Не вижу в том ответе обоснования необходимости наследования.
AVK>А я не говорил что наследование необходимо. Необходимо средство динамической диспетчеризации.
Безусловно. Это средство — возможность реализации интерфейса несколькими классами. Без наследования интерфейсов и классов.
ARK>>Заменяем "выносишь общую часть разных интерфейсов в одного предка" на "выносишь общую часть разных интерфейсов в один отдельный интерфейс" — все остальное то же самое.
AVK>Там по ссылке есть ответ, в чем разница. И, на всякий случай — реализация интерфейса в классе это тоже наследование контракта. Интерфейсы, как я понимаю, ты отменять не собираешься, значит и наследование как таковое никуда не девается. Т.е. те же яйца, вид в профиль.
Можно пойти дальше — отменить интерфейсы как типы, сделать их сущностями, пригодными исключительно для констраинтов. Т.е. чтобы нельзя было объявить переменную типа "интерфейс", только переменную типа "это класс, какой — мы не знаем, но он точно реализует этот интерфейс".
Так что никакого наследования и совсем не те же яйца. Мне такой вариант даже больше нравится.
ARK>>это вопрос синтаксиса, наверное можно сделать что-то типа alias'ов.
AVK>А зачем? Наследование интерфейсов прекрасно эту задачу решает.
Но заодно привносит type cast, который тянет за собой еще гору проблем.
ARK>> Перечислять тонну хлама в генериках тоже ведь накладно.
AVK>Ну вот пока не приходится тонну хлама перечислять.
Бывает, что и приходится. List<Dictionary<string, KeyValuePair<int, int>>> и прочая.
ARK>>Третий пункт, честно, не очень понял. Что именно наследование задает, повышает и накладывает. Зачем IButton должен быть отнаследован от IControl?
AVK>Семантика такая. Я интерфейс IButton проектирую из рассчета, что это контрол. Наследование позволяет этот мой рассчет зафиксировать явно, с проверкой компилятором.
ОК. Хотя необходимость этого тоже под вопросом. Сегодня это winforms-контрол, а завтра контрол из WPF или метро.
ARK>>Полиморфизм нужен. Алгебраические типы — неплохо. А зачем нужно наследование
AVK>Затем же, зачем и алгебраические типы.
AVK>>>Мне вот интересно — ты действительно считаешь, что наследование не имеет отношения к динамической диспетчеризации, или это прием спора такой?
ARK>>Наследование безусловно имеет отношение к динамической диспетчеризации.
AVK>Уже хорошо. Тогда поясни, к чему фраза про то, что в викишной статье про наследование ни слова?
Видимо дело в том, что я не считаю реализацию интерфейса одной из форм наследования. Хотя это вопрос терминологический и дискуссионный.
ARK>> Это одна из форм динамической диспетчеризации. Но не единственная
AVK>А что, кто то утверждал что единственная?
ARK>> и, более того, по моему мнению, не нужная
AVK>Отлично, что взамен?
Взамен — написал выше вариант.
ARK>>. В Haskell динамическая диспетчеризация есть, а наследования нет.
AVK>В Хаскеле есть ФВП и нет классов и 100% кода построено на этих ФВП. Естественно, наследование там не нужно, да и неприменимо.
Ну вот я и хотел сказать, что динамик диспатч и наследование не являются связанными сущностями.
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Да ты не ответил. AVK>Ответил. И оценки говорят, что, как минимум, еще 3 человека считают так же. То что ответ тебе не нравится — я тут не виноват.
Ответ на вопрос "зачем?" должен, очевидно, приводить какую-то причину. Ты ее не привел, а переформулировал вопрос в других словах. Разделить один интерфейс на несколько — ОК, понятно. А вот зачем их еще при этом наследовать ты, боюсь, не объяснил.
И да, мне казалось, тут не спортивное соревнование, чтобы побежал тот, у кого наберется больше "очков".
ВВ>>Не понимаю, честно говоря, какое отношение АлгТД имеют к динамик диспатчу. AVK>Прямое. Единственный их смысл — применение в комплекте с PM (сами по себе, без РМ, это малополезный артефакт). А РМ по АлгТД решает именно что задачу динамической диспетчеризации.
Ну при таком подходе можно сказать, что if по integer-ам решает задачу динамической диспетчеризации.
ВВ>>А ты правда считаешь, что динамик диспатч возможен только при наследовании? AVK>Попробуй привести цитату, где я подобное утверждаю.
Ну вот хотя бы: AVK>Мне вот интересно — ты действительно считаешь, что наследование не имеет отношения к динамической диспетчеризации, или это прием спора такой?
Кстати, вполне может не иметь
ВВ>> Достаточно утиной типизации вообще-то. AVK>AlexRK ничего про нее не писал.
Он писал о том, что для динамик диспатча наследование не нужно. Что есть правда. Как, впрочем, и обратное утверждение.
Здравствуйте, AndrewVK, Вы писали:
ВВ>>Ну речь же про наследование. AVK>Речь про отмену наследования.
Ну очевидно надо сначала разобраться, что мы решили отменять.
ВВ>> И тайпклассы, с рядом оговорок, это не динамик диспатч. AVK>Т.е ты сам придумал, что тайпклассы это ДД, и сам же с блеском опровергнул?
Чего? Где придумал? Где я вообще говорил, что это ДД??
Instance selection обычно статический.
ВВ>>А с ФВП ты сам прекрасно ответил на вопрос, как же возможен динамик диспатч без наследования. AVK>А такого вопроса никто не задавал. Вопрос был к AlexRK, как он предполагает реализовывать ДД.
Речь идет о запрете наследования интерфейсов между собой. Реализация интерфейсов остается. Наследование классов, кстати, тоже можно убрать
При наличии возможности описывать тип как совокупность интерфейсов, полученная в результате такой редукции система может иметь лишь проблему с "неудобным" подключением реализации.
И по ходу все
Вопрос, собственно — где я не прав?
ВВ>> Что, кстати, уже начинает наводить на подозрения AVK>Ага, на то, что кто то толи не читает топик, толи не понимает смысл прочитанного.
Если кто-то превратно понимает то, что ты пишешь — нас, кстати, уже двое, и мы одинаково тебя неправильно поняли (а ты же любишь голоса считать, или нам тут третьего подождать?) — то причина может быть и в том, что сформулировано неудачно. Проще, наверное, переформулировать, чем выдвигать предположения о том, что с тобой спорят и при этом тебя не читают.
