Здравствуйте, samius, Вы писали:
S>Здравствуйте, Voblin, Вы писали:
V>>Полиморфизьм основывается на наследовании. S>Это ошибочное утверждение
Если говорить о наследовании как о некой синтаксической конструкции, которая один класс назначает потомком другого, то да. Но если абстрагироваться от механизмов реализации, то получается, что нет.
Смысл-то полиморфизма в том, чтобы любой функции F, рассчитывающей получить на вход объект класса С1 можно подсунуть С2 если... ну да, если С2 по всем интерфейсам, задействованным функцией F полностью аналогичен C1. То есть с точки зрения F является ничем иным как C1. То есть, по сути, унаследовал интерфейсы от C1.
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, AlexRK, Вы писали:
ARK>>И что за зверь "обработки"? ARK>>Вот тут есть обработки? ARK>>
ARK>> interface IBase { }
ARK>> class A : IBase { }
ARK>> class B : IBase { }
ARK>>
_>Этот код ничего не делает, и не есть иллюстрация полиморфизма. Минимум надо создать объект, и присвоить переменной. "Создать" и "присвоить" — операции, которые зависят от типа.
Здравствуйте, samius, Вы писали:
S>>>Я не разделяю вашу тягу к выдумыванию определений. _>>Это измененное определение, неправильное, чтобы соответствовало твоим функциям.
S>А какое тогда правильное? То, которое делает AddInt и AddFloat полиморфными друг другу?
Я понять не могу, где в определении допускается разная обработка да еще разных типов.
S>>>И не вижу причин давать определение полиморфизму в рамках реляционной модели, в то время как типы определены в теории типов.
_>>А что такое интерфейс? S>http://en.wikipedia.org/wiki/Interface_%28computing%29
То есть интерфейс — это (абстрактный) тип.
Если перефразировать определение из вики.
Обработка данных разного типа посредством общего/одинакового абстрактного типа (интерфейса).
Упрощаем и получаем, обработка данных в зависимости от типа (общего абстрактного).
Здравствуйте, Mystic, Вы писали:
V>>Чё-то как-то совсем плохо себе представляю, чтобы система с одной стороны была единым целым, а с другой стороны — минимум взаимовлияния подсистем. V>>Тут уж либо первое, либо второе...
M>Ну... например Unix-way --- много программ, каждая из которых умеет делать что-то одно (но хорошо). Изменения в исходниках grep не затрагивают какой-нить ls.
Way может быть любым, но система — это всегда единое целое, становящееся системой только тогда, когда появляется системный эффект. То есть тогда, когда целое больше простой суммы частей. А это появляется тогда и только тогда, когда части взаимозависимы. И чем больше они взаимозависимы, тем больше системный эффект.
Grep + ls не дают систему. Это просто два инструмента. Как отвёртка и молоток.
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, Voblin, Вы писали:
V>>>Полиморфизьм основывается на наследовании. S>>Это ошибочное утверждение
V>Если говорить о наследовании как о некой синтаксической конструкции, которая один класс назначает потомком другого, то да. Но если абстрагироваться от механизмов реализации, то получается, что нет.
V>Смысл-то полиморфизма в том, чтобы любой функции F, рассчитывающей получить на вход объект класса С1 можно подсунуть С2 если... ну да, если С2 по всем интерфейсам, задействованным функцией F полностью аналогичен C1. То есть с точки зрения F является ничем иным как C1. То есть, по сути, унаследовал интерфейсы от C1.
V>Таки в чём же ошибочность утверждения?
Очевидно, что автор имел в виду наследование как стандартный механизм в мейнстрим ООП-языках. Поэтому его утверждение ошибочно.
Если же говорить "по сути" (что бы это ни значило) — то приведите свое определение наследования. А то получится как у Фоменко, где он из одного слова перестановками букв получает совершенно другое и утверждает, что они тождественны.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, fin_81, Вы писали:
_>>Здравствуйте, AlexRK, Вы писали:
ARK>>>И что за зверь "обработки"? ARK>>>Вот тут есть обработки? ARK>>>
ARK>>> interface IBase { }
ARK>>> class A : IBase { }
ARK>>> class B : IBase { }
ARK>>>
_>>Этот код ничего не делает, и не есть иллюстрация полиморфизма. Минимум надо создать объект, и присвоить переменной. "Создать" и "присвоить" — операции, которые зависят от типа.
ARK>Хорошо. На остальные вопросы ответов не будет?
Обработка — применение операций. Операции зависят от типа. Результат операции зависит от конкретного экземпляра-параметра(ов). Экземпляр может принадлежать разным типам-множествам.
_>Не уследил за базаром, старею.
_>На это отвечу. Это оговорка про смолтолк. Со своим представлением о полиморфизме, где любому объекту можно было посылать любое сообщение.
Милнер ссылается на полиморфизм в ALGOL-е. Причем смолток со своим представлением о полиморфизме?
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>>>Полиморфизьм основывается на наследовании. S>>Это ошибочное утверждение
V>Если говорить о наследовании как о некой синтаксической конструкции, которая один класс назначает потомком другого, то да. Но если абстрагироваться от механизмов реализации, то получается, что нет.
нет, не получается. Механизмы реализации не играют роли.
V>Смысл-то полиморфизма в том, чтобы любой функции F, рассчитывающей получить на вход объект класса С1 можно подсунуть С2 если... ну да, если С2 по всем интерфейсам, задействованным функцией F полностью аналогичен C1. То есть с точки зрения F является ничем иным как C1. То есть, по сути, унаследовал интерфейсы от C1.
V>Таки в чём же ошибочность утверждения?
В том что для проявления полиморфизма объекты должны обладать какими-то родственными интерфейсами. Это не так в общем случае. В частном — да, верно.
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, samius, Вы писали:
_>>>А что такое интерфейс? S>>http://en.wikipedia.org/wiki/Interface_%28computing%29
_>То есть интерфейс — это (абстрактный) тип. _>Если перефразировать определение из вики.
Нет, я сослался на общее определение интерфейса, а не на частное для ООП языков.
_>Обработка данных разного типа посредством общего/одинакового абстрактного типа (интерфейса).
_>Упрощаем и получаем, обработка данных в зависимости от типа (общего абстрактного).
sin a/cos a = in/co
Здравствуйте, samius, Вы писали:
S>Милнер ссылается на полиморфизм в ALGOL-е.
Я не знаю алгол. Нужен пример полиморфизма в алголе, что посложнее перегрузки функций.
S>Причем смолток со своим представлением о полиморфизме?
Ответ на требование а причем тут ооп в контексте smalltalk.
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, samius, Вы писали:
S>>Милнер ссылается на полиморфизм в ALGOL-е. _>Я не знаю алгол. Нужен пример полиморфизма в алголе, что посложнее перегрузки функций.
Куда сложнее, если перегрузка функций и есть одно из проявлений полиморфизма? ООП-шный полиморфизм это есть частный случай перегрузки функций по неявному аргументу.
S>>Причем смолток со своим представлением о полиморфизме? _>Ответ на требование а причем тут ооп в контексте smalltalk.
Это был ответ на вопрос, был ли полиморфизм до smalltalk-а. И в нем откуда-то взялось ООП.
Здравствуйте, samius, Вы писали:
V>>>>Полиморфизьм основывается на наследовании. S>>>Это ошибочное утверждение _>>В каком мейнстримном языке программирования? S>Затрудняюсь сказать, в каком это действительно так.
Здравствуйте, AlexRK, Вы писали:
ARK>Очевидно, что автор имел в виду наследование как стандартный механизм в мейнстрим ООП-языках. Поэтому его утверждение ошибочно.
ARK>Если же говорить "по сути" (что бы это ни значило) — то приведите свое определение наследования. А то получится как у Фоменко, где он из одного слова перестановками букв получает совершенно другое и утверждает, что они тождественны.
За определением можно сходить в википедию. Не в определениях счастье. В ООП нам обещано счастье, заключающееся в том, что если есть реализованный кем-то класс, мы можем не особо перенапрягаясь сделать ему свой собственный модный тюнинг.
Для всякой мелочёвки типа модных тюнингов это наверняка зашибись, но... когда нужно построить небоскрёб, предложение найти хибарку и от неё унаследоваться — это чистое издевательство.
И ещё большее издевательство — требовать от строителей небоскрёба, чтобы от продукта их труда можно было при желании унаследовать какой-нибудь милый особнячок.
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, AlexRK, Вы писали:
ARK>>Очевидно, что автор имел в виду наследование как стандартный механизм в мейнстрим ООП-языках. Поэтому его утверждение ошибочно.
ARK>>Если же говорить "по сути" (что бы это ни значило) — то приведите свое определение наследования. А то получится как у Фоменко, где он из одного слова перестановками букв получает совершенно другое и утверждает, что они тождественны.
V>За определением можно сходить в википедию.
Можно, но вы используете какое-то свое определение, как я понял.
V>Не в определениях счастье. В ООП нам обещано счастье, заключающееся в том, что если есть реализованный кем-то класс, мы можем не особо перенапрягаясь сделать ему свой собственный модный тюнинг. V>Для всякой мелочёвки типа модных тюнингов это наверняка зашибись, но... когда нужно построить небоскрёб, предложение найти хибарку и от неё унаследоваться — это чистое издевательство. V>И ещё большее издевательство — требовать от строителей небоскрёба, чтобы от продукта их труда можно было при желании унаследовать какой-нибудь милый особнячок.
Не понял, как это все относится к обсуждению истинности первоначального утверждения о полиморфизме и наследовании.
Здравствуйте, fin_81, Вы писали:
_>Обработка — применение операций. Операции зависят от типа. Результат операции зависит от конкретного экземпляра-параметра(ов). Экземпляр может принадлежать разным типам-множествам.
ОК. Итак:
int AddInt(int, int)
float AddFloat(float, float)
Обработка есть. Обе операции зависят от типов. Их результаты тоже. Вердикт — обе функции полиморфны.
Здравствуйте, AlexRK, Вы писали:
ARK>Не понял, как это все относится к обсуждению истинности первоначального утверждения о полиморфизме и наследовании.
ОК. Давайте от обратного. Берём ООП и делаем ему "минус наследование".
Как-то почти автоматически получается "минус полиморфизм". Но мы не сдаёмся и пытаемся организовать полиморфизм без использования наследования. И, о чудо! В конце концов у нас это получается! Однако, порывшись в своих соображениях, которыми мы руководствовались когда проектировали все связки-взаимоувязки, проанализировав код, приходим к выводу, что нам таки пришлось спроектировать иерархию классов. Пусть неявно, пусть на бумажке, но сделать это пришлось.
Полиморфизм — прямое следствие наследования. И не важно, поддержано оно средствами ЯП или нам пришлось как-то ещё выкручиваться.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, samius, Вы писали:
V>>>>>Полиморфизьм основывается на наследовании. S>>>>Это ошибочное утверждение _>>>В каком мейнстримном языке программирования? S>>Затрудняюсь сказать, в каком это действительно так.
Q>JavaScript.
Объекты в JS не нуждаются в отношении наследования для проявления полиморфизма.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, samius, Вы писали:
S>>Объекты в JS не нуждаются в отношении наследования для проявления полиморфизма.
Q>Ну, я это и имел в виду.
А, так я как раз затруднился привести язык, в котором полиморфизм был бы "основан на наследовании". То есть не имел бы других проявлений, кроме как subtype polymorphism.
Здравствуйте, AlexRK, Вы писали:
ARK>ОК. Итак:
ARK>int AddInt(int, int) ARK>float AddFloat(float, float)
ARK>Обработка есть. Обе операции зависят от типов. Их результаты тоже. Вердикт — обе функции полиморфны.
Полиморфизм — это обработка ...
Обработка разная, применяем разные операции — обламываемся на слове "обработка", дальнейшее уточнение не важно. Единственное число, не все возможные обработки, а конкретная.
