Re[9]: Инкаспуляция, наследование, полиморфизм - Философия программирования

Все это такое фуфло, я вас скажу эти ваши философии. Так же как и много других умных слов про программирование. На практике же, надо просто решать конкретную прикладную задачу, вот и все. И в результате оказывается, что умные программеры во всем коде на C# (!) во всю используют глобальные переменные! Как на старом добром Фортране — везде фигурирует MainForm.Instance.CurCofig.бла-бла. Ну и че? Это плохо? Нет — это нормально. Потому что софта работает и выполняет свою задачу. Ну это наверное мое личное мировосприятие — программирование является лишь вспомогательным инструментом для решения более серьезных задач, инженерного и научного типа. И пофигу на весь этот ваш умный computer science, тем более, что иногда приходится объяснять, что поделить на 10 это не то же, что умножить на 0.1 — вот в чем заключается computer science, а не в том, что бы наследовать хрень от белиберды или наоборот.

MS>Все это такое фуфло, я вас скажу эти ваши философии. Так же как и много других умных слов про программирование.
Кто-то, судя по всему, неправильно выбрал профессию.

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

V>Полиморфизьм основывается на наследовании.
Это ошибочное утверждение

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

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

V>>>Полиморфизьм основывается на наследовании.
S>>Это ошибочное утверждение
_>В каком мейнстримном языке программирования?

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

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

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

_>>И так возвращаясь к сути. Множество состоящее из наследования — это подмножество полиморфизма?

A>Наследование, само по себе, не является полиморфизмом. Наследование — это лишь механизм, позволяющий добиться динамического ad-hoc полиморфизма (по типу неявно передаваемого параметра this) в языках программирования, в который наследование имеет "subtyping" семантику (грубо говоря, разрешено приведение к базовому типу). Вполне возможен такой язык (причем, он будет OO языком), в котором есть наследование, но запрещено явное и неявное приведение к базовому классу (чтобы нельзя было нарушить LSP), а ОО-шный полиморфизм делается только на интерфейсах.
Более того, мы знаем такой язык. В нём достаточно написать class B: private A, как мы тут же потеряем способность передавать ссылки на B в произвольный код, ожидающий A. Т.е. наследование — есть, а полиморфизма — нету.

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

_>>Кстати реляционная модель хорошо описывает "связь" между данными. Предположу что все три определения ООП хорошо ложатся на реляционную модель. А реляционную модель достаточно строгая мат. модель.

S>Жду определение полиморфизма из реляционной алгебры... Ну или хоть какое-то, что бы можно было обсуждать что-то кроме предположений.

Возьмем определение: полиморфизм — это обработка данных в зависимости от типа.

Тип
Данные
Операция
Отношение Тип-Данные
Отношение Тип-Операция

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

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

ARK>>Не понял, как это все относится к обсуждению истинности первоначального утверждения о полиморфизме и наследовании.

V>ОК. Давайте от обратного. Берём ООП и делаем ему "минус наследование".
V>Как-то почти автоматически получается "минус полиморфизм". Но мы не сдаёмся и пытаемся организовать полиморфизм без использования наследования. И, о чудо! В конце концов у нас это получается! Однако, порывшись в своих соображениях, которыми мы руководствовались когда проектировали все связки-взаимоувязки, проанализировав код, приходим к выводу, что нам таки пришлось спроектировать иерархию классов. Пусть неявно, пусть на бумажке, но сделать это пришлось.

V>Полиморфизм — прямое следствие наследования. И не важно, поддержано оно средствами ЯП или нам пришлось как-то ещё выкручиваться.

Нет, полиморфизм не имеет ничего общего с наследованием. Идеальный ООП-язык, с моей точки зрения, не должен иметь наследования ни в каком виде (в том числе и наследования интерфейсов). Полиморфизм — через реализацию интерфейсов.

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

_>И так возвращаясь к сути. Множество состоящее из наследования — это подмножество полиморфизма?

Наследование, само по себе, не является полиморфизмом. Наследование — это лишь механизм, позволяющий добиться динамического ad-hoc полиморфизма (по типу неявно передаваемого параметра this) в языках программирования, в который наследование имеет "subtyping" семантику (грубо говоря, разрешено приведение к базовому типу). Вполне возможен такой язык (причем, он будет OO языком), в котором есть наследование, но запрещено явное и неявное приведение к базовому классу (чтобы нельзя было нарушить LSP), а ОО-шный полиморфизм делается только на интерфейсах.

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

MS>Все это такое фуфло, я вас скажу эти ваши философии.

Aw Jeez, Not This Shit Again.jpg

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

J>Но вброс на самом деле имеет следующий смысл: насколько практический программер должен сражаться за теоретическую чистоту кода?
Теоретическая чистота когда — это как?
Мол, "вот вам говнокод, который теоретически был бы чистым, если бы не... ", так?

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

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

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

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

_>>>>Возьмем определение: полиморфизм — это обработка данных в зависимости от типа.
S>>>Негодное определение, т.к. допускает ложные срабатывания.
S>>>По нему int AddInt(int, int) и float AddFloat(float, float) полиморфны.

_>>Обработка разная, операции разные.
S>Ваше определение допускает.

Тогда определение должно выглядеть так
полиморфизм — это все возможные обработки данных в зависимости от типа

_>>>>Тип
_>>>>Данные
_>>>>Операция
_>>>>Отношение Тип-Данные
_>>>>Отношение Тип-Операция

S>>>Что за звери "операция", "отношение"?

_>>Значения, между которыми есть отношения.
S>Но термин "значение" вам был не угоден, а теперь вы на него ссылаетесь при определении операции и отношения.
S>Ну и что что есть отношения. У ежиков тоже отношения могут быть.
"Значение" — это определение из реляционной модели. "Отношение" — это тоже определение из реляционной модели. Реляционная модель — строгая математическая модель с алгеброй. Возможно эти определения по другому называются.

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

S>>>Я не разделяю вашу тягу к выдумыванию определений.
_>>Это измененное определение, неправильное, чтобы соответствовало твоим функциям.

S>А какое тогда правильное? То, которое делает AddInt и AddFloat полиморфными друг другу?
Я понять не могу, где в определении допускается разная обработка да еще разных типов.

S>>>И не вижу причин давать определение полиморфизму в рамках реляционной модели, в то время как типы определены в теории типов.

_>>А что такое интерфейс?
S>http://en.wikipedia.org/wiki/Interface_%28computing%29

То есть интерфейс — это (абстрактный) тип.
Если перефразировать определение из вики.

Обработка данных разного типа посредством общего/одинакового абстрактного типа (интерфейса).

Упрощаем и получаем, обработка данных в зависимости от типа (общего абстрактного).

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

S>>>Объекты в JS не нуждаются в отношении наследования для проявления полиморфизма.
Q>>Ну, я это и имел в виду.
S>А, так я как раз затруднился привести язык, в котором полиморфизм был бы "основан на наследовании". То есть не имел бы других проявлений, кроме как subtype polymorphism.

Из контекста у меня создалось впечатление, что fin_81 имел в виду полиморфизм-в-узком-смысле, а именно «динамический полиморфизм, основанный на переопределении функций». JavaScript — это мейнстримный язык, который как нельзя лучше опровергает постулат о связи полиморфизма-в-указанном-смысле с наследованием.

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

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

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

S>>Как бы вам популярно объяснить суть предлагаемой вами цепочки рассуждений?
S>>Представьте мешок с картошкой. Картофелина входит в этот мешок. Картофелина — это мешок с картошкой?
S>Пардон. Следовало сформулировать так: картофелина — это подмножество мешка с картошкой?

Не плодим сущности.
Есть множество картофелин.
картофелина — это подмножество множества картофелин.

Здравствуйте, samius, Вы писали:
S>В общем случае для второго класса нехарактерно владение таким уровнем классификации. В быту многие до пенсии (и после) называют все металлические предметы железяками.
Это понятно. Непонятно такое же невладение на профессиональном форуме.
Ну, то есть оно, наверное, объяснимо — какие-то негодяи тридцать лет внедряли мисконцепцию "ООП = инкапсуляция, наследование, полиморфизм", что привело к смешенью умов. Но всё равно вызывает разочарование как само невладение, так и отказ воспринимать корректную картину мира.

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

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

ARK>>Не понял, как это все относится к обсуждению истинности первоначального утверждения о полиморфизме и наследовании.

V>ОК. Давайте от обратного. Берём ООП и делаем ему "минус наследование".
V>Как-то почти автоматически получается "минус полиморфизм". Но мы не сдаёмся и пытаемся организовать полиморфизм без использования наследования. И, о чудо! В конце концов у нас это получается! Однако, порывшись в своих соображениях, которыми мы руководствовались когда проектировали все связки-взаимоувязки, проанализировав код, приходим к выводу, что нам таки пришлось спроектировать иерархию классов. Пусть неявно, пусть на бумажке, но сделать это пришлось.

V>Полиморфизм — прямое следствие наследования. И не важно, поддержано оно средствами ЯП или нам пришлось как-то ещё выкручиваться.

http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
http://rsdn.ru/forum/philosophy/2853873

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

MS>Все это такое фуфло, я вас скажу эти ваши философии. Так же как и много других умных слов про программирование. На практике же, надо просто решать конкретную прикладную задачу, вот и все. И в результате оказывается, что умные программеры во всем коде на C# (!) во всю используют глобальные переменные! Как на старом добром Фортране — везде фигурирует MainForm.Instance.CurCofig.бла-бла. Ну и че? Это плохо? Нет — это нормально. Потому что софта работает и выполняет свою задачу. Ну это наверное мое личное мировосприятие — программирование является лишь вспомогательным инструментом для решения более серьезных задач, инженерного и научного типа. И пофигу на весь этот ваш умный computer science, тем более, что иногда приходится объяснять, что поделить на 10 это не то же, что умножить на 0.1 — вот в чем заключается computer science, а не в том, что бы наследовать хрень от белиберды или наоборот.

Часто — да. Но для разработки большой и сложной системы с длительным циклом переделки и доработки в будущем эти штуки весьма полезны.

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

MS>Все это такое фуфло, я вас скажу эти ваши философии. Так же как и много других умных слов про программирование. На практике же, надо просто решать конкретную прикладную задачу, вот и все. И в результате оказывается, что умные программеры во всем коде на C# (!) во всю используют глобальные переменные! Как на старом добром Фортране — везде фигурирует MainForm.Instance.CurCofig.бла-бла. Ну и че? Это плохо? Нет — это нормально. Потому что софта работает и выполняет свою задачу. Ну это наверное мое личное мировосприятие — программирование является лишь вспомогательным инструментом для решения более серьезных задач, инженерного и научного типа.

С этим я совершенно согласен.

MS>И пофигу на весь этот ваш умный computer science, тем более, что иногда приходится объяснять, что поделить на 10 это не то же, что умножить на 0.1 — вот в чем заключается computer science, а не в том, что бы наследовать хрень от белиберды или наоборот.

А с этим — нет. Когда в решении начинают участвовать мегатонны кода, становится очень важно, хрень там от белиберды или наоборот. Потому, что если не так как надо, то придется переписать 10 мегатонн или добавлять еще 5 мегатонн совершеннейших макарон. Это другая сложность, не алгоритмическая. Тем не менее проблема актуальная и от нее никуда не уйти.

Но я последнее время начал понимать, что даже в мегатоннах кода, MainForm.Instance.CurCofig работает иногда лучше других решений. И это хорошо.

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

MS>Все это такое фуфло, я вас скажу эти ваши философии. Так же как и много других умных слов про программирование. На практике же, надо просто решать конкретную прикладную задачу, вот и все. И в результате оказывается, что умные программеры во всем коде на C# (!) во всю используют глобальные переменные! Как на старом добром Фортране — везде фигурирует MainForm.Instance.CurCofig.бла-бла. Ну и че? Это плохо? Нет — это нормально. Потому что софта работает и выполняет свою задачу. Ну это наверное мое личное мировосприятие — программирование является лишь вспомогательным инструментом для решения более серьезных задач, инженерного и научного типа. И пофигу на весь этот ваш умный computer science, тем более, что иногда приходится объяснять, что поделить на 10 это не то же, что умножить на 0.1 — вот в чем заключается computer science, а не в том, что бы наследовать хрень от белиберды или наоборот.

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

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

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

MS>>Все это такое фуфло, я вас скажу эти ваши философии. .... И пофигу на весь этот ваш умный computer science,... или наоборот.

A>понимаешь, в science за каждой вещью стоит куча статей объясняющих почему оно нужно, в т.ч. с примерами.

Ну философия такая наука

Когда встречаются три философа

— они выдвигают пять ортогональных теорий

,
причём каждый может с аргументами как доказать

, так и опровергнуть любую из них

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

V>>>>Полиморфизьм основывается на наследовании.
S>>>Это ошибочное утверждение
_>>В каком мейнстримном языке программирования?
S>Затрудняюсь сказать, в каком это действительно так. Но речь не о конкретном языке, а о значении термина в CS.

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

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

S>Мне вполне ничего определение из википедии.
S>

S>In computer science, polymorphism is a programming language feature that allows values of different data types to be handled using a uniform interface.

Что-то слишком много предупреждений в начале статьи. Значения, типы, интерфейсы — что за звери, и чем они отличаются друг от друга.

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

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

S>>Мне вполне ничего определение из википедии.
S>>

S>>In computer science, polymorphism is a programming language feature that allows values of different data types to be handled using a uniform interface.

_>Что-то слишком много предупреждений в начале статьи. Значения, типы, интерфейсы — что за звери, и чем они отличаются друг от друга.

А вы хотите определение полиморфизма без типов и значений? У меня такого нет. Может у вас? Только я спрошу сразу, что за зверь "наследование"

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

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

S>>А вы хотите определение полиморфизма без типов и значений? У меня такого нет. Может у вас? Только я спрошу сразу, что за зверь "наследование"

_>Кстати реляционная модель хорошо описывает "связь" между данными. Предположу что все три определения ООП хорошо ложатся на реляционную модель. А реляционную модель достаточно строгая мат. модель.

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

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

MS>>Все это такое фуфло, я вас скажу эти ваши философии. Так же как и много других умных слов про программирование.
B>Кто-то, судя по всему, неправильно выбрал профессию.

Точно. Мало того, еще и одну из лучших векторных библиотек AGG написал. Гнать из профессии мокрыми тряпками.

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

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

MS>>>Все это такое фуфло, я вас скажу эти ваши философии. Так же как и много других умных слов про программирование.
B>>Кто-то, судя по всему, неправильно выбрал профессию.

J>Точно. Мало того, еще и одну из лучших векторных библиотек AGG написал. Гнать из профессии мокрыми тряпками.

Не знаю как с наследованием, но инкапсуляции и полиморфизма в AGG по самые гланды. Так что, расцениваю заглавное сообщение как вброс.

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

_>Тогда определение должно выглядеть так
_>полиморфизм — это все возможные обработки данных в зависимости от типа

Что значит "все возможные" и "в зависимости от типа"?

И что за зверь "обработки"?

Вот тут есть обработки?

  interface IBase { }
  class A : IBase { }
  class B : IBase { }

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

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

_>>>А другие способы реализации полиморфизма являются частью языков программирования?

A>>да, являются.

_>Утиная типизация — полиморфизм? В каком языке он есть?

Есть в C#.

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

_>>>А другие способы реализации полиморфизма являются частью языков программирования?

A>>да, являются.

_>Утиная типизация — полиморфизм? В каком языке он есть?

типизация это типизация, полиморфизм это полиморфизм.

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

_>Утиная типизация — полиморфизм? В каком языке он есть?

C++ подойдёт?..

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

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

S>>>>По нему int AddInt(int, int) и float AddFloat(float, float) полиморфны.

_>>>Обработка разная, операции разные.
S>>Ваше определение допускает.

_>Тогда определение должно выглядеть так
_>полиморфизм — это все возможные обработки данных в зависимости от типа

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

_>>>Значения, между которыми есть отношения.
S>>Но термин "значение" вам был не угоден, а теперь вы на него ссылаетесь при определении операции и отношения.
S>>Ну и что что есть отношения. У ежиков тоже отношения могут быть.
_>"Значение" — это определение из реляционной модели. "Отношение" — это тоже определение из реляционной модели. Реляционная модель — строгая математическая модель с алгеброй. Возможно эти определения по другому называются.
Я пока не улавливаю связь полиморфизма с реляционной моделью.
И не вижу причин давать определение полиморфизму в рамках реляционной модели, в то время как типы определены в теории типов.

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

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

ARK>>Очевидно, что автор имел в виду наследование как стандартный механизм в мейнстрим ООП-языках. Поэтому его утверждение ошибочно.

ARK>>Если же говорить "по сути" (что бы это ни значило) — то приведите свое определение наследования. А то получится как у Фоменко, где он из одного слова перестановками букв получает совершенно другое и утверждает, что они тождественны.

V>За определением можно сходить в википедию.

Можно, но вы используете какое-то свое определение, как я понял.

V>Не в определениях счастье. В ООП нам обещано счастье, заключающееся в том, что если есть реализованный кем-то класс, мы можем не особо перенапрягаясь сделать ему свой собственный модный тюнинг.
V>Для всякой мелочёвки типа модных тюнингов это наверняка зашибись, но... когда нужно построить небоскрёб, предложение найти хибарку и от неё унаследоваться — это чистое издевательство.
V>И ещё большее издевательство — требовать от строителей небоскрёба, чтобы от продукта их труда можно было при желании унаследовать какой-нибудь милый особнячок.

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

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

J>Это как в Java, когда раз ООП, то не должно быть свободных функций, и поэтому надо рожать бессмысленные классы для свободных по сути функций типа синуса и main. Зато чистый ООП, только классы.

J>Или там "из функции должен быть только один выход", потому что типа Дейкстра доказал, что такие функции лучше — и поэтому начинаются пляски с тем же goto, лишь бы return в середине функции не написать.

Да я понимаю все.
У меня есть гипотеза: все программисты проходят через период идеологического пуризма, когда кажется, что некая логически стройная и элегантная парадигма — это истинный путь, а остальное надо выбросить все на свалку истории. Ничего, с опытом проходит.

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

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

S>>

S>>Термин полиморфизм обозначает семейство различных механизмов, позволяющих использовать один и тот же фрагмент программы с различными типами в различных контекстах.

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

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

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

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

V>Grep + ls не дают систему. Это просто два инструмента. Как отвёртка и молоток.

А в итоге они образуют binutils, набор инструментов позволяющий решать задачи администрирования.

Хотя возможно твое мнение еще связано с решаемыми тобой задачами. Вдруг ты только в школе преподаешь. Или занимаешься уж черезчур низкоуровневым программированием (01000111011000010111100101000111...)

Здравствуйте, samius, Вы писали:
S>Милнер ссылается на работу C.Strachey 1967-го года с предположением что именно там впервые был предложен термин. Там же упоминаются параметрический и специальный виды полиморфизма. Про subtype polymorphism ничего не было. Как было на самом деле — не знаю.
Выглядит правдоподобно.

З.Ы. Весь разговор напоминает мне спор по материаловедению, который я как-то проиграл однокласснику во втором классе. Он обратился к ещё одному однокласснику, чтоб тот рассудил нас: "прикинь, Антон говорит, что металл — это тоже железо!!!".

Спор был спровоцирован вопросом про то, можно ли считать медь железом. Я всего лишь пытался объяснить, что и медь и железо являются металлами, но ни один из них не является друг другом. Увы — такая концепция слишком далеко выходила за рамки доступной одноклассникам классификации материалов.

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

_>На результат могут повлиять только конкретные значения параметров. А типы на входе этой операции одни и те же, они не могут влиять на результат даже в общем случае.

На результат могут влиять типы параметров. На входе типы разные — А и его наследники. И оператор может возвращать разные типы в качестве результата (А или его наследника).

ARK>>Не полиморфен, он работает только с целыми числами.
_>Нет он работает и с типом А.

Нет, он не работает с типом А.

ARK>>Фактически, ваш код полностью эквивалентен "x = i + Convert.ToInt(a)".
_>Фактически любой код эквивалентен машинным кодам.

Я говорю о семантике языка, а не о особенностях реализации (которой вообще может не существовать). По правилам языка "x = i + a" эквивалентно "x = i + Convert.ToInt(a)" при условии наличия приведения A к int. Оператор + не полиморфен.

_>Чем этот пример отличается от предыдущего, котрый используюет наследование для приведения типа.

"Наследование для приведения типа"? Вы меня извините, но, как мне кажется, у вас полная каша в голове. Разберитесь с основными понятиями ООП, можно начать с википедии.

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

_DA>http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
_DA>http://rsdn.ru/forum/philosophy/2853873

За ссылочки спасибо. Особенно хорошо доставляет вторая.

А вообще я в растерянности. Народ прицепился к фразе "Полиморфизьм основывается на наследовании" и устроил дикий холивар на тему того, так это или не так?

Ну конечно же, это не есть абсолютная истина в последней инстанции. Это даже скорее похоже на полуправду. Сам делал много раз что-то вроде "плагинных систем". Иногда — вообще безо всякого "ОО".

А смысл-то моего поста был вообще не в этом. Сказать-то я хотел, что обещанное идеологами ООП счастье возможно, но возможно только локально, по-мелочи и не надолго. При проектировании чего-то действительно большого и сложного лучше всего выбросить из головы всю эту чушь. Доверять надо не рекламным материалам производителей средств разработки, а собственному опыту, интуиции и чувству прекрасного.
Попытаться втиснуть себя в прокрустово ложе любой идеологии — это проиграть в гибкости и свободе манёвра.

Так что забейте, господа, на вопрос "облажался ли Voblin, сказав, что полиморфизм основывается на наследовании". Не облажался. Просто это — полуправда, покрывающая собой изрядный кусок мэйнстрима. Через наследование полиморфизм организуется проще всего. Лёгким движением руки. Но, понятное дело, это не единственный способ. Есть ещё сто тысяч способов это сделать.

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

Здравствуйте, samius, Вы писали:
S>При единственной задаче софта "работать" — самое тупое решение, при котором софт будет работать, является оптимальным.

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

S>А когда у вашего софта наметятся другие задачи, тогда и обсудим, как на них скажутся глобальные переменные и MainForm.Instance.CurConfig.бла-бла.

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

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

S>>Про полиморфизм всё уже сказано здесь: http://rsdn.ru/forum/philosophy/2853873
_>

_>Хочу заметить что там сказано что наследование — это механизм параметрического полиморфизма, а предыдущий оратор пишет что это механизм ad-hoc полиморфизма. Кто-то врет.
Давай на примере объясню.
Дано:

abstract class Base
{
 public abstract void F();
}

class A : Base
{
  public override void F() { Console.WriteLine("A"); }
}

class B : Base
{
  public override void F() { Console.WriteLine("B"); }
}

Использование:

Base o = ...
o.F(); // тут ad-hoc полиморфизм - выбор реализации метода делается на основе фактического типа переменной 'o'

Еще:

void DoSomething(int n, Base o)
{
  for(int i=0; i<n; ++i)
    o.F();
}

Метод DoSomething параметрически полиморфен по параметру 'o', в том смысле, что одна и та же реализация для любого наследника Base.

Чтобы это стало очевидней, определение DoSomething по смыслу ближе всего к следующему:

void DoSomething<T>(int n, T o)
  where T: Base
{
  for(int i=0; i<n; ++i)
    o.F();
}

В этом смысле наследование это "механизм параметрического полиморфизма" — оно нужно чтобы иметь возможность писать такие вот параметрически полиморфные методы; без такой возможности оно нафиг не нужно.

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

0>>Теоретическая чистота когда — это как?

J>Или там "из функции должен быть только один выход", потому что типа Дейкстра доказал, что такие функции лучше — и поэтому начинаются пляски с тем же goto, лишь бы return в середине функции не написать.

Прошу прощения, что вмешиваюсь. И наверняка обсуждение на эту тему встречается, и поэтому писать стоило бы туда.
Цитата на всякий случай..
из "Чистый код" Р. Мартина (гл. 3, "Функции"):

Структурное программирование

Некоторые программисты следуют правилам структурного программирования, изложенным Эдгаром Дейкстрой [SP72]. Дейкстра считает, что каждая функция и каждый блок внутри функции должны иметь одну точку входа и одну точку выхода. Выполнение этого правила означает, что функция должна содержать только одну команду return, в циклах не должны использоваться команды break или continue, а команды goto не должны использоваться никогда и ни при каких условиях.

Хотя мы с симпатией относимся к целям и методам структурного программирования, в очень компактных функциях эти правила не приносят особой пользы. Только при увеличении объема функций их соблюдение обеспечивает существенный эффект.

Итак, если ваши функции остаются очень компактными, редкие вкрапления множественных return, команд break и continue не принесут вреда, а иногда даже повышают выразительность по сравнению с классической реализацией с одной точкой входа и одной точкой выхода. С другой стороны, команда goto имеет смысл только в больших функциях, поэтому ее следует избегать.

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

J>Или там "из функции должен быть только один выход", потому что типа Дейкстра доказал, что такие функции лучше — и поэтому начинаются пляски с тем же goto, лишь бы return в середине функции не написать.
Один выход это фигня. Мне для генерации кода функции с несколькими точками входа нужны.

Но в .НЕТ всё жёстко... придётся в натив уходить...

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

MS>Все это такое фуфло, я вас скажу эти ваши философии. Так же как и много других умных слов про программирование. На практике же, надо просто решать конкретную прикладную задачу, вот и все. И в результате оказывается, что умные программеры во всем коде на C# (!) во всю используют глобальные переменные! Как на старом добром Фортране — везде фигурирует MainForm.Instance.CurCofig.бла-бла. Ну и че? Это плохо? Нет — это нормально. Потому что софта работает и выполняет свою задачу.
При единственной задаче софта "работать" — самое тупое решение, при котором софт будет работать, является оптимальным. Т.к. компьютеру поровну, какие инструкции выполнять.

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

Взять, к примеру, человеческий фактор. То что вы тут решили пообсуждать глобальные переменные и MainForm.Instance — уже отвлекает вас от работы. Что плохо для вашей работы, но не для софта, который работает и уже выполняет свою задачу.

Здравствуйте, Географ, Вы писали:

MS>>Все это такое фуфло, я вас скажу эти ваши философии. [...]
Г>Часто — да. Но для разработки большой и сложной системы с длительным циклом переделки и доработки в будущем эти штуки весьма полезны.

Согласен, что "да" — часто. И особенно часто в случае разработки большой и сложной системы с длительным циклом переделки и доработки.

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

Гораздо лучше, когда единственный вариант наследования — это непосредственное наследование от заранее жёстко определённого набора базовых классов. Я сам сейчас работаю с такой средой разработки и всё, уверяю вас, очень шоколадненько. И постоянно дополняющиеся/меняющиеся/уточняющиеся функциональные требования не убивают.

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

V>>Полиморфизьм основывается на наследовании.
S>Это ошибочное утверждение
В каком мейнстримном языке программирования?

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

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

V>>>Полиморфизьм основывается на наследовании.
S>>Это ошибочное утверждение
_>В каком мейнстримном языке программирования?
Затрудняюсь сказать, в каком это действительно так. Но речь не о конкретном языке, а о значении термина в CS.

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

V>>>>Полиморфизьм основывается на наследовании.
S>>>Это ошибочное утверждение
_>>В каком мейнстримном языке программирования?

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

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

Чувствию разговор перейдет в плоскость ООП vs ЯП.

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

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

S>>Затрудняюсь сказать, в каком это действительно так. Но речь не о конкретном языке, а о значении термина в CS.

_>Жду непротиворечивого определения полиморфизма без использования способов реализации в конкретных языках.
_>Первоначально в смолтолке это было что-то похожее на обработку сообщений.

Мне вполне ничего определение из википедии.

In computer science, polymorphism is a programming language feature that allows values of different data types to be handled using a uniform interface.

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

_>Первоначально в смолтолке это было что-то похожее на обработку сообщений.
А что, до смолтока полиморфизма не было?

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

S>А что, до смолтока полиморфизма не было?

До смолтока почти ничего не было.

"Appeared in 1972 (development began in 1969)"

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

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

S>>А что, до смолтока полиморфизма не было?

DM>До смолтока почти ничего не было.

DM>"Appeared in 1972 (development began in 1969)"
Ну да! Симула-67 уже была.

DM>"Appeared in 1972 (development began in 1969)"

"C" ведь был. ALGOL был.

Здравствуйте, Географ, Вы писали:

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

Г>Часто — да. Но для разработки большой и сложной системы с длительным циклом переделки и доработки в будущем эти штуки весьма полезны.

Имхо, тут более полезно умение разделить систему на отдельные подсистемы, влияние которых друг на друга сведено к минимуму. На классах это сделать можно, но обычно класс слишком уж мелкая единица для такого разбиения.

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

_>>Первоначально в смолтолке это было что-то похожее на обработку сообщений.
S>А что, до смолтока полиморфизма не было?
Не могу знать. Но похоже этого определения не было в CS до появления смолтолка. А полиморфизм скорее всего представлялся как перегрузка функций, возможно додумались до виртуальных методов. Появление ООП вроде связывают со смолтолком.

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

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

_>А другие способы реализации полиморфизма являются частью языков программирования?

да, являются.

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

_>>Что-то слишком много предупреждений в начале статьи. Значения, типы, интерфейсы — что за звери, и чем они отличаются друг от друга.

S>А вы хотите определение полиморфизма без типов и значений? У меня такого нет. Может у вас? Только я спрошу сразу, что за зверь "наследование"

Кстати реляционная модель хорошо описывает "связь" между данными. Предположу что все три определения ООП хорошо ложатся на реляционную модель. А реляционную модель достаточно строгая мат. модель.

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

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

S>>А что, до смолтока полиморфизма не было?
_>Не могу знать. Но похоже этого определения не было в CS до появления смолтолка. А полиморфизм скорее всего представлялся как перегрузка функций, возможно додумались до виртуальных методов. Появление ООП вроде связывают со смолтолком.

"Похоже" — это как-то не аргумент против определения в википедии. Может и не было определения, мне сложно об этом судить, но явления, описываемые в определении, явно имели место. А причем тут ООП? Инкапсуляция тоже не в ООП была рождена. Да и наследование (subtyping) тоже.

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

_>Жду непротиворечивого определения полиморфизма без использования способов реализации в конкретных языках.
_>Первоначально в смолтолке это было что-то похожее на обработку сообщений.

У меня в закладках лежит вот это: http://www.rsdn.ru/forum/philosophy/2853873.1
Неоднократно перечитанное.
Нифига на практике ни разу не пригодившееся.

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

S>Так что, расцениваю заглавное сообщение как вброс.

К гадалке не ходи

Но вброс на самом деле имеет следующий смысл: насколько практический программер должен сражаться за теоретическую чистоту кода?

Вот тут рядом был вброс на тему goto, смысл тот же.

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

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

_>>>Кстати реляционная модель хорошо описывает "связь" между данными. Предположу что все три определения ООП хорошо ложатся на реляционную модель. А реляционную модель достаточно строгая мат. модель.

S>>Жду определение полиморфизма из реляционной алгебры... Ну или хоть какое-то, что бы можно было обсуждать что-то кроме предположений.

_>Возьмем определение: полиморфизм — это обработка данных в зависимости от типа.
Негодное определение, т.к. допускает ложные срабатывания.
По нему int AddInt(int, int) и float AddFloat(float, float) полиморфны.

_>Тип
_>Данные
_>Операция
_>Отношение Тип-Данные
_>Отношение Тип-Операция

Что за звери "операция", "отношение"?

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

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

_>>Возьмем определение: полиморфизм — это обработка данных в зависимости от типа.
S>Негодное определение, т.к. допускает ложные срабатывания.
S>По нему int AddInt(int, int) и float AddFloat(float, float) полиморфны.

Обработка разная, операции разные.

_>>Тип
_>>Данные
_>>Операция
_>>Отношение Тип-Данные
_>>Отношение Тип-Операция

S>Что за звери "операция", "отношение"?

Значения, между которыми есть отношения.

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

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

J>К гадалке не ходи

J>Но вброс на самом деле имеет следующий смысл: насколько практический программер должен сражаться за теоретическую чистоту кода?

Если обратить внимание на то, что термины, перечисленные в заголовке темы, напоминают трех китов, часто приписываемых ООП, то вообще говоря, сражаться за чистоту ООП ради самой чистоты или ООП не вижу смысла.
Ну а сами термины и обозначаемые ими явления — достаточно полезные для практического программирования.
Другое дело что можно достаточно успешно применять обсуждаемые вещи на практике, не зная самих терминов и/или их принятых в CS определений.
Т.е. на пальцах без умных слов "- тут так будет лучше, потому что позволит нам решить такие-то проблемы в перспективе".

J>Вот тут рядом был вброс на тему goto, смысл тот же.
Не согласен. Здесь ведь не стоит вопрос, применять или не применять. Тут поставлен вопрос, надо ли заморачиваться теорией, что бы принять решение, наследовать ли "хрень от белиберды". Если это кто-то делает по наитию и у него получается хороший результат — ветер в спину. Но бывает и наоборот, что углубленный в теорию программист получает фиговый результат в коде. Так что, я не знаю, что тут обсуждать. Если теория мешает кому-то писать код, то нафиг такую теорию тогда. Осмелюсь предположить что мне помогает. Хоть не считаю себя продвинутым теоретиком.

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

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

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

S>>>А что, до смолтока полиморфизма не было?
_>>Не могу знать. Но похоже этого определения не было в CS до появления смолтолка. А полиморфизм скорее всего представлялся как перегрузка функций, возможно додумались до виртуальных методов. Появление ООП вроде связывают со смолтолком.

S>"Похоже" — это как-то не аргумент против определения в википедии.
Равнозначный аргумент.

S>Может и не было определения, мне сложно об этом судить, но явления, описываемые в определении, явно имели место. А причем тут ООП? Инкапсуляция тоже не в ООП была рождена. Да и наследование (subtyping) тоже.

Явления можно объяснить несколькими моделями: полиморфизмом, обработкой сообщений, типизацией, теорией категорий (я его не знаю) и тп. Но вопрос "А причем тут ООП?" остается.

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

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

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

_>>>Возьмем определение: полиморфизм — это обработка данных в зависимости от типа.
S>>Негодное определение, т.к. допускает ложные срабатывания.
S>>По нему int AddInt(int, int) и float AddFloat(float, float) полиморфны.

_>Обработка разная, операции разные.
Ваше определение допускает.

_>>>Тип
_>>>Данные
_>>>Операция
_>>>Отношение Тип-Данные
_>>>Отношение Тип-Операция

S>>Что за звери "операция", "отношение"?

_>Значения, между которыми есть отношения.
Но термин "значение" вам был не угоден, а теперь вы на него ссылаетесь при определении операции и отношения.
Ну и что что есть отношения. У ежиков тоже отношения могут быть.

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

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

S>>"Похоже" — это как-то не аргумент против определения в википедии.
_>Равнозначный аргумент.
Т.е. вы против статьи в википедии ставите свое "похоже" и считаете это равнозначным? Не, пусть будет так, но я против вашего "похоже" заряжу свое "не похоже". Далее обсуждение можно заканчивать.

S>>Может и не было определения, мне сложно об этом судить, но явления, описываемые в определении, явно имели место. А причем тут ООП? Инкапсуляция тоже не в ООП была рождена. Да и наследование (subtyping) тоже.

_>Явления можно объяснить несколькими моделями: полиморфизмом, обработкой сообщений, типизацией, теорией категорий (я его не знаю) и тп. Но вопрос "А причем тут ООП?" остается.
А кто первый вспомнил про ООП в данной теме? Вот к нему и вопрос.

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

_>Возьмем определение: полиморфизм — это обработка данных в зависимости от типа.

И чем это определение лучше википедийного?

Те же неопределенные термины "данные", "операции", "значения", "типы" и "обработка". Что за звери, и чем они отличаются друг от друга? (с)

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

_>>А другие способы реализации полиморфизма являются частью языков программирования?

A>да, являются.

Утиная типизация — полиморфизм? В каком языке он есть?

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

ARK>И что за зверь "обработки"?

ARK>Вот тут есть обработки?
ARK>

ARK>  interface IBase { }
ARK>  class A : IBase { }
ARK>  class B : IBase { }
ARK>

Этот код ничего не делает, и не есть иллюстрация полиморфизма. Минимум надо создать объект, и присвоить переменной. "Создать" и "присвоить" — операции, которые зависят от типа.

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

M>Имхо, тут более полезно умение разделить систему на отдельные подсистемы, влияние которых друг на друга сведено к минимуму. На классах это сделать можно, но обычно класс слишком уж мелкая единица для такого разбиения.

Чё-то как-то совсем плохо себе представляю, чтобы система с одной стороны была единым целым, а с другой стороны — минимум взаимовлияния подсистем.
Тут уж либо первое, либо второе...

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

S>>>Может и не было определения, мне сложно об этом судить, но явления, описываемые в определении, явно имели место. А причем тут ООП? Инкапсуляция тоже не в ООП была рождена. Да и наследование (subtyping) тоже.

_>>Явления можно объяснить несколькими моделями: полиморфизмом, обработкой сообщений, типизацией, теорией категорий (я его не знаю) и тп. Но вопрос "А причем тут ООП?" остается.
S>А кто первый вспомнил про ООП в данной теме? Вот к нему и вопрос.

В данной ветке — ты, отвечай.

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

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

S>>А кто первый вспомнил про ООП в данной теме? Вот к нему и вопрос.

_>В данной ветке — ты, отвечай.
Ответ неверный
http://www.rsdn.ru/forum/philosophy/5133134.1
http://www.rsdn.ru/forum/philosophy/5133245.1

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

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

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

S>>>А кто первый вспомнил про ООП в данной теме? Вот к нему и вопрос.

_>>В данной ветке — ты, отвечай.
S>Ответ неверный
S>http://www.rsdn.ru/forum/philosophy/5133134.1
S>http://www.rsdn.ru/forum/philosophy/5133245.1

Это другие ветки, там другие войны. Отвечай.

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

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

S>>>>А кто первый вспомнил про ООП в данной теме? Вот к нему и вопрос.

_>>>В данной ветке — ты, отвечай.
S>>Ответ неверный
S>>http://www.rsdn.ru/forum/philosophy/5133134.1
S>>http://www.rsdn.ru/forum/philosophy/5133245.1

_>Это другие ветки, там другие войны. Отвечай.

В этой ветке тоже, хотя речь была о теме.
http://www.rsdn.ru/forum/philosophy/5133245.1

З.Ы. Что за командный тон?

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

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

M>>Имхо, тут более полезно умение разделить систему на отдельные подсистемы, влияние которых друг на друга сведено к минимуму. На классах это сделать можно, но обычно класс слишком уж мелкая единица для такого разбиения.

V>Чё-то как-то совсем плохо себе представляю, чтобы система с одной стороны была единым целым, а с другой стороны — минимум взаимовлияния подсистем.
V>Тут уж либо первое, либо второе...

Ну... например Unix-way --- много программ, каждая из которых умеет делать что-то одно (но хорошо). Изменения в исходниках grep не затрагивают какой-нить ls.

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

_>>Тогда определение должно выглядеть так
_>>полиморфизм — это все возможные обработки данных в зависимости от типа

S>Я не разделяю вашу тягу к выдумыванию определений.
Это измененное определение, неправильное, чтобы соответствовало твоим функциям.

S>Я пока не улавливаю связь полиморфизма с реляционной моделью.
S>И не вижу причин давать определение полиморфизму в рамках реляционной модели, в то время как типы определены в теории типов.

А что такое интерфейс?

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

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

_>>>полиморфизм — это все возможные обработки данных в зависимости от типа

S>>Я не разделяю вашу тягу к выдумыванию определений.
_>Это измененное определение, неправильное, чтобы соответствовало твоим функциям.

А какое тогда правильное? То, которое делает AddInt и AddFloat полиморфными друг другу?

S>>И не вижу причин давать определение полиморфизму в рамках реляционной модели, в то время как типы определены в теории типов.

_>А что такое интерфейс?
http://en.wikipedia.org/wiki/Interface_%28computing%29

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

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

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

S>>>>>А кто первый вспомнил про ООП в данной теме? Вот к нему и вопрос.

_>>>>В данной ветке — ты, отвечай.
S>>>Ответ неверный
S>>>http://www.rsdn.ru/forum/philosophy/5133134.1
S>>>http://www.rsdn.ru/forum/philosophy/5133245.1

_>>Это другие ветки, там другие войны. Отвечай.

S>В этой ветке тоже, хотя речь была о теме.
S>http://www.rsdn.ru/forum/philosophy/5133245.1

Не уследил за базаром, старею.

На это отвечу. Это оговорка про смолтолк. Со своим представлением о полиморфизме, где любому объекту можно было посылать любое сообщение.

Здравствуйте, 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>>

_>Этот код ничего не делает, и не есть иллюстрация полиморфизма. Минимум надо создать объект, и присвоить переменной. "Создать" и "присвоить" — операции, которые зависят от типа.

Хорошо. На остальные вопросы ответов не будет?

Здравствуйте, 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>Хорошо. На остальные вопросы ответов не будет?

Обработка — применение операций. Операции зависят от типа. Результат операции зависит от конкретного экземпляра-параметра(ов). Экземпляр может принадлежать разным типам-множествам.

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

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

S>>В этой ветке тоже, хотя речь была о теме.
S>>http://www.rsdn.ru/forum/philosophy/5133245.1

_>Не уследил за базаром, старею.

_>На это отвечу. Это оговорка про смолтолк. Со своим представлением о полиморфизме, где любому объекту можно было посылать любое сообщение.
Милнер ссылается на полиморфизм в 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-а. И в нем откуда-то взялось ООП.

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

ARK>Очевидно, что автор имел в виду наследование как стандартный механизм в мейнстрим ООП-языках. Поэтому его утверждение ошибочно.

ARK>Если же говорить "по сути" (что бы это ни значило) — то приведите свое определение наследования. А то получится как у Фоменко, где он из одного слова перестановками букв получает совершенно другое и утверждает, что они тождественны.

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

Для всякой мелочёвки типа модных тюнингов это наверняка зашибись, но... когда нужно построить небоскрёб, предложение найти хибарку и от неё унаследоваться — это чистое издевательство.
И ещё большее издевательство — требовать от строителей небоскрёба, чтобы от продукта их труда можно было при желании унаследовать какой-нибудь милый особнячок.

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

_>Обработка — применение операций. Операции зависят от типа. Результат операции зависит от конкретного экземпляра-параметра(ов). Экземпляр может принадлежать разным типам-множествам.

ОК. Итак:

int AddInt(int, int)
float AddFloat(float, float)

Обработка есть. Обе операции зависят от типов. Их результаты тоже. Вердикт — обе функции полиморфны.

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

ARK>Не понял, как это все относится к обсуждению истинности первоначального утверждения о полиморфизме и наследовании.

ОК. Давайте от обратного. Берём ООП и делаем ему "минус наследование".
Как-то почти автоматически получается "минус полиморфизм". Но мы не сдаёмся и пытаемся организовать полиморфизм без использования наследования. И, о чудо! В конце концов у нас это получается! Однако, порывшись в своих соображениях, которыми мы руководствовались когда проектировали все связки-взаимоувязки, проанализировав код, приходим к выводу, что нам таки пришлось спроектировать иерархию классов. Пусть неявно, пусть на бумажке, но сделать это пришлось.

Полиморфизм — прямое следствие наследования. И не важно, поддержано оно средствами ЯП или нам пришлось как-то ещё выкручиваться.

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

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

V>>>>>Полиморфизьм основывается на наследовании.
S>>>>Это ошибочное утверждение
_>>>В каком мейнстримном языке программирования?
S>>Затрудняюсь сказать, в каком это действительно так.

Q>JavaScript.

Объекты в JS не нуждаются в отношении наследования для проявления полиморфизма.

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

S>Объекты в JS не нуждаются в отношении наследования для проявления полиморфизма.

Ну, я это и имел в виду.

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

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

S>>Объекты в JS не нуждаются в отношении наследования для проявления полиморфизма.

Q>Ну, я это и имел в виду.
А, так я как раз затруднился привести язык, в котором полиморфизм был бы "основан на наследовании". То есть не имел бы других проявлений, кроме как subtype polymorphism.

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

ARK>ОК. Итак:

ARK>int AddInt(int, int)
ARK>float AddFloat(float, float)

ARK>Обработка есть. Обе операции зависят от типов. Их результаты тоже. Вердикт — обе функции полиморфны.

Полиморфизм — это обработка ...
Обработка разная, применяем разные операции — обламываемся на слове "обработка", дальнейшее уточнение не важно. Единственное число, не все возможные обработки, а конкретная.

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

MS>Все это такое фуфло, я вас скажу эти ваши философии. Так же как и много других умных слов про программирование. На практике же, надо просто решать конкретную прикладную задачу, вот и все.

Когда то, ради чего делалась задача, малость (или не совсем малость) перестало быть актуально _после_ затраченных усилий на задачу, то станет понятно что твои слова бесполезный bullshit. Т.к. заглянуть в будущее и узнать какова будет жизнь после выполнения задачи могут немногие люди. Ещё меньшее кол-во людей может предсказать как будет развиваться жизнь и соответственно сделанная в ней задача во времени. А измениться может так, что надо будет много чего переделать.
Поэтому лучше подстелить соломку, чем не стелить

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

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

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

_>>>>А что такое интерфейс?
S>>>http://en.wikipedia.org/wiki/Interface_%28computing%29

_>>То есть интерфейс — это (абстрактный) тип.
_>>Если перефразировать определение из вики.
S>Нет, я сослался на общее определение интерфейса, а не на частное для ООП языков.

И как совместить это общее определение с теорией типов?

_>>Обработка данных разного типа посредством общего/одинакового абстрактного типа (интерфейса).

_>>Упрощаем и получаем, обработка данных в зависимости от типа (общего абстрактного).
S>sin a/cos a = in/co
Что это?

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

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

S>>Нет, я сослался на общее определение интерфейса, а не на частное для ООП языков.

_>И как совместить это общее определение с теорией типов?
Найти в нем что-то общее с определениями, близкими к теории типов. Например, у Пирса:

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

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

_>>>Обработка данных разного типа посредством общего/одинакового абстрактного типа (интерфейса).

_>>>Упрощаем и получаем, обработка данных в зависимости от типа (общего абстрактного).
S>>sin a/cos a = in/co
_>Что это?
Это упрощение, подобное вашему.

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

S>>>Милнер ссылается на полиморфизм в ALGOL-е.
_>>Я не знаю алгол. Нужен пример полиморфизма в алголе, что посложнее перегрузки функций.
S>Куда сложнее, если перегрузка функций и есть одно из проявлений полиморфизма? ООП-шный полиморфизм это есть частный случай перегрузки функций по неявному аргументу.

Где пример полиморфизма на алгол?

S>>>Причем смолток со своим представлением о полиморфизме?
_>>Ответ на требование а причем тут ооп в контексте smalltalk.
S>Это был ответ на вопрос, был ли полиморфизм до smalltalk-а. И в нем откуда-то взялось ООП.

В университетах учили что это первый ОО язык.

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

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

J>>Но вброс на самом деле имеет следующий смысл: насколько практический программер должен сражаться за теоретическую чистоту кода?

0>Теоретическая чистота когда — это как?

Это как в Java, когда раз ООП, то не должно быть свободных функций, и поэтому надо рожать бессмысленные классы для свободных по сути функций типа синуса и main. Зато чистый ООП, только классы.

Или там "из функции должен быть только один выход", потому что типа Дейкстра доказал, что такие функции лучше — и поэтому начинаются пляски с тем же goto, лишь бы return в середине функции не написать.

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

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

S>>Куда сложнее, если перегрузка функций и есть одно из проявлений полиморфизма? ООП-шный полиморфизм это есть частный случай перегрузки функций по неявному аргументу.

_>Где пример полиморфизма на алгол?
Бан в гугле за манеры?
http://en.wikipedia.org/wiki/Operator_overloading#1960s

S>>Это был ответ на вопрос, был ли полиморфизм до smalltalk-а. И в нем откуда-то взялось ООП.

_>В университетах учили что это первый ОО язык.
Осталось выяснить, причем тут ОО.

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

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

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

S>>>Куда сложнее, если перегрузка функций и есть одно из проявлений полиморфизма? ООП-шный полиморфизм это есть частный случай перегрузки функций по неявному аргументу.

_>>Где пример полиморфизма на алгол?
S>Бан в гугле за манеры?
S>http://en.wikipedia.org/wiki/Operator_overloading#1960s
Перегрузка операторов.

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

S>>>Это был ответ на вопрос, был ли полиморфизм до smalltalk-а. И в нем откуда-то взялось ООП.

_>>В университетах учили что это первый ОО язык.
S>Осталось выяснить, причем тут ОО.
А что не ОО язык?

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

S>>>Нет, я сослался на общее определение интерфейса, а не на частное для ООП языков.

_>>И как совместить это общее определение с теорией типов?
S>Найти в нем что-то общее с определениями, близкими к теории типов. Например, у Пирса:
S>

S>Термин полиморфизм обозначает семейство различных механизмов, позволяющих использовать один и тот же фрагмент программы с различными типами в различных контекстах.

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

Под это определение прекрасно подходит наследование. Наследование — это полиморфизм?

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

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

ARK>>ОК. Итак:

ARK>>int AddInt(int, int)
ARK>>float AddFloat(float, float)

ARK>>Обработка есть. Обе операции зависят от типов. Их результаты тоже. Вердикт — обе функции полиморфны.

_>Полиморфизм — это обработка ...
_>Обработка разная, применяем разные операции — обламываемся на слове "обработка", дальнейшее уточнение не важно. Единственное число, не все возможные обработки, а конкретная.

Вот видите, сколько появляется всяких разных слов (причем я до конца все равно не понял). А определение должно быть коротким, полным и непротиворечивым (по возможности). Определение полиморфизма из википедии очень хорошее и использует известные в CS термины.

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

S>>http://en.wikipedia.org/wiki/Operator_overloading#1960s
_>Перегрузка операторов.

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

Перегрузка операторов — это один из видов полиморфизма.

_>А что не ОО язык?

Pascal, Haskell.

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

MS>На практике же, надо просто решать конкретную прикладную задачу, вот и все.
Это просто замечательно

Предлагаю развить мысль: фуфло все эти ваши языки программирования, зачем они? Надо просто решать конкретную прикладную задачу

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

_>Под это определение прекрасно подходит наследование. Наследование — это полиморфизм?

Наследование — это повторное использование реализации + полиморфизм. Таким образом, термины "наследование" и "полиморфизм" не эквивалентны.

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

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

S>>http://en.wikipedia.org/wiki/Operator_overloading#1960s
_>Перегрузка операторов.

_>А я думал сейчас будет эмуляция таблицы вирт методов.
Это таблица виртуальных методов будет эмуляцией перегрузки для рантайма.
_>Скоро вывод типов в функциональных языках запишут в примеры полиморфизма.
Прокомментирую когда запишут. Я таких тенденций не наблюдаю.

_>>>В университетах учили что это первый ОО язык.
S>>Осталось выяснить, причем тут ОО.
_>А что не ОО язык?
Содержательная часть беседы кончилась?

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

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

_>>Под это определение прекрасно подходит наследование. Наследование — это полиморфизм?

ARK>Наследование — это повторное использование реализации + полиморфизм. Таким образом, термины "наследование" и "полиморфизм" не эквивалентны.

По приведенному определению: повторное использование реализации — это полиморфизм.
Вывод: наследование — полиморфизм + полиморфизм.
Весело чо

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

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

S>>>http://en.wikipedia.org/wiki/Operator_overloading#1960s
_>>Перегрузка операторов.

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

ARK>Перегрузка операторов — это один из видов полиморфизма.

Наследование — тоже один из видов полиморфизма.
Программирование — тоже один из видов полиморфизма.
Биологическая жизнь — тоже один из видов полиморфизма.
Вселенная — тоже один из видов полиморфизма.

Еще веселее

_>>А что не ОО язык?

ARK>Pascal, Haskell.

Мне показалось, что было поставлено под сомнение что smalltalk OO язык? Я спрашиваю — почему?

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

_>Мне показалось, что было поставлено под сомнение что smalltalk OO язык? Я спрашиваю — почему?
Показалось. Изначально я спрашивал "А что, до смолтока полиморфизма не было?".
А потом вас зациклило. Свое упоминание смолтока вы связываете с его ОО-шностью, а упоминание ООП с тем что смолток имеет к нему отношение.

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

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

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

S>>>

S>>>Термин полиморфизм обозначает семейство различных механизмов, позволяющих использовать один и тот же фрагмент программы с различными типами в различных контекстах.

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

_>>Под это определение прекрасно подходит наследование. Наследование — это полиморфизм?
S>Предлагаю различать механизм как способ установки взаимоотношения между типами и свойство программы, которое он обеспечивает.

Еще раз по-русски. Полиморфизм — это семейство механизмов, в это семейство входит наследование. Правильно? Наследование — это подмножество полиморфизма?

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

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

_>Еще раз по-русски. Полиморфизм — это семейство механизмов, в это семейство входит наследование. Правильно? Наследование — это подмножество полиморфизма?

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

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

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

S>Как бы вам популярно объяснить суть предлагаемой вами цепочки рассуждений?
S>Представьте мешок с картошкой. Картофелина входит в этот мешок. Картофелина — это мешок с картошкой?
Пардон. Следовало сформулировать так: картофелина — это подмножество мешка с картошкой?

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

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

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

S>>>http://en.wikipedia.org/wiki/Operator_overloading#1960s
_>>Перегрузка операторов.

_>>А я думал сейчас будет эмуляция таблицы вирт методов.
S>Это таблица виртуальных методов будет эмуляцией перегрузки для рантайма.
А обработка сообщений — тоже эмуляция перегрузки? Чую, скоро и полиморфизм — станет подмножеством перегрузки функции.

_>>Скоро вывод типов в функциональных языках запишут в примеры полиморфизма.
S>Прокомментирую когда запишут. Я таких тенденций не наблюдаю.
Под определение в другой ветке подходит.

_>>>>В университетах учили что это первый ОО язык.
S>>>Осталось выяснить, причем тут ОО.
_>>А что не ОО язык?
S>Содержательная часть беседы кончилась?
А что спросить то хотел? Я ответил про причем тут ОО в контексте смолтолка. Жду твоего ответа.

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

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

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

_>>>Под это определение прекрасно подходит наследование. Наследование — это полиморфизм?

ARK>>Наследование — это повторное использование реализации + полиморфизм. Таким образом, термины "наследование" и "полиморфизм" не эквивалентны.

_>По приведенному определению: повторное использование реализации — это полиморфизм.
_>Вывод: наследование — полиморфизм + полиморфизм.
_>Весело чо

Повторное использование реализации — это НЕ полиморфизм.

Борщ — это мясо + капуста. Борщ — это не мясо, мясо это не борщ, борщ не капуста и капуста не борщ.

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

ARK>>Перегрузка операторов — это один из видов полиморфизма.
_>Наследование — тоже один из видов полиморфизма.

Наследование — один из видов полиморфизма, но не единственный, не главный и не лучший. Просто один из. Деталь реализации, а не часть определения.

ARK>>Pascal, Haskell.
_>Мне показалось, что было поставлено под сомнение что smalltalk OO язык? Я спрашиваю — почему?

А, это я чего-то не понял тогда.

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

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

_>>Мне показалось, что было поставлено под сомнение что smalltalk OO язык? Я спрашиваю — почему?
S>Показалось. Изначально я спрашивал "А что, до смолтока полиморфизма не было?".

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

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

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

_>>>А я думал сейчас будет эмуляция таблицы вирт методов.
S>>Это таблица виртуальных методов будет эмуляцией перегрузки для рантайма.
_>А обработка сообщений — тоже эмуляция перегрузки? Чую, скоро и полиморфизм — станет подмножеством перегрузки функции.
Что-то я не поспеваю за такой чуйкой.

_>>>Скоро вывод типов в функциональных языках запишут в примеры полиморфизма.
S>>Прокомментирую когда запишут. Я таких тенденций не наблюдаю.
_>Под определение в другой ветке подходит.
Не вижу связи

S>>>>Осталось выяснить, причем тут ОО.
_>>>А что не ОО язык?
S>>Содержательная часть беседы кончилась?
_>А что спросить то хотел? Я ответил про причем тут ОО в контексте смолтолка. Жду твоего ответа.

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

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

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

S>>Показалось. Изначально я спрашивал "А что, до смолтока полиморфизма не было?".

_>Вопрос для тех кто знает историю. Интересно когда появляется определение полиморфизм в комп. науке. А то выяснится что под общее определение полиморфизма можно приписать развитие вселенной начиная большого взрыва.
Милнер ссылается на работу C.Strachey 1967-го года с предположением что именно там впервые был предложен термин. Там же упоминаются параметрический и специальный виды полиморфизма. Про subtype polymorphism ничего не было. Как было на самом деле — не знаю.

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

ARK>Повторное использование реализации — это НЕ полиморфизм.

допустим есть язык допускающий наследование операторов

class A { operator+(A) {} }
class B : A {}
class C : A {}

B b1,b2;
B b3 = b1 + b3;

C c1,c2;
C c3 = c1 + c2;

Типы разные, повторно использую реализацию operator+. Тут ест полиморфизм? И еще приведение типов — полиморфизм?

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

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

ARK>>Повторное использование реализации — это НЕ полиморфизм.

_>допустим есть язык допускающий наследование операторов

_>

_>class A { operator+(A) {} }
_>class B : A {}
_>class C : A {}

_>B b1,b2;
_>B b3 = b1 + b3;

_>C c1,c2;
_>C c3 = c1 + c2;
_>

_>Типы разные, повторно использую реализацию operator+. Тут ест полиморфизм?

Где именно "тут"? Если речь про оператор +, то он полиморфен, да. Обрабатывает разные типы.

_>И еще приведение типов — полиморфизм?

Приведение типов в мейнстримовых языках — это синтаксическая конструкция языка. К синтаксическим конструкциям термин "полиморфизм" неприменим, по крайней мере общепринятые определения этого не подразумевают.

Если же взять, скажем, Eiffel, в котором все приведения типов — обычные функции, то там эти функции не полиморфны.

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

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

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

ARK>>>Повторное использование реализации — это НЕ полиморфизм.

_>>допустим есть язык допускающий наследование операторов

_>>

_>>class A { operator+(A) {} }
_>>class B : A {}
_>>class C : A {}

_>>B b1,b2;
_>>B b3 = b1 + b3;

_>>C c1,c2;
_>>C c3 = c1 + c2;
_>>

_>>Типы разные, повторно использую реализацию operator+. Тут ест полиморфизм?

ARK>Где именно "тут"? Если речь про оператор +, то он полиморфен, да. Обрабатывает разные типы.
Повторно используется реализация оператор+. Этот оператор полиморфен. Повторное использование — это не полиморфизм. Где-то здесь противоречие.

_>>И еще приведение типов — полиморфизм?

ARK>Приведение типов в мейнстримовых языках — это синтаксическая конструкция языка. К синтаксическим конструкциям термин "полиморфизм" неприменим, по крайней мере общепринятые определения этого не подразумевают.

ARK>Если же взять, скажем, Eiffel, в котором все приведения типов — обычные функции, то там эти функции не полиморфны.

с++, конструкторы и операторы приведения operator int(). Как это разрешается во время синтаксического разбора, построения аст?

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

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

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

ARK>>>ОК. Итак:

ARK>>>int AddInt(int, int)
ARK>>>float AddFloat(float, float)

ARK>>>Обработка есть. Обе операции зависят от типов. Их результаты тоже. Вердикт — обе функции полиморфны.

_>>

_>>Полиморфизм — это обработка ...
_>>Обработка разная, применяем разные операции — обламываемся на слове "обработка", дальнейшее уточнение не важно. Единственное число, не все возможные обработки, а конкретная.

ARK>Вот видите, сколько появляется всяких разных слов (причем я до конца все равно не понял). А определение должно быть коротким, полным и непротиворечивым (по возможности). Определение полиморфизма из википедии очень хорошее и использует известные в CS термины.

полиморфизм — выполнение конкретной операции в зависимости от типа данных.
Забыл артикль the (конкретный)

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

хотел себя сдержать, и поэтому сдержу.
то, о чем ты написал, может быть правдоподобно для маленького компонента к.л. приложения (или для очень-очень маленького приложения) м.б. <1000строк, про который точно известно, что от него требуется и изменяться он не будет никогда. В остальных случаях — твои слова "ни о чем".
Неужели ты не писал приложения объемом чуть больше названного выше? Или не вносил множество изменений\дополнений после первой реализации? Потому что если бы было иначе, то ты понял бы неудобство всех этих глобальных переменных, "goto", и пр. Не дураки и не просто так придумали и используют ООП и множество принципов проектирования.
Хотя наверное твое сообщение стеб и отвечать тебе не стоило.

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

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

MS>>На практике же, надо просто решать конкретную прикладную задачу, вот и все.
0>Это просто замечательно

0>Предлагаю развить мысль: фуфло все эти ваши языки программирования, зачем они? Надо просто решать конкретную прикладную задачу

Ну некоторые языки действительно фуфло

А еще больше фуфловаты только в некоторых аспектах

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

V>ОК. Давайте от обратного. Берём ООП и делаем ему "минус наследование".

Получаем машинку, в которой все объекты умеют QueryInterface...

Для того, что бы реализовывать интерфейсы наследование вообще-то не нужно и не обязательно ни разу...

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

_>>>Упрощаем и получаем, обработка данных в зависимости от типа (общего абстрактного).
S>>sin a/cos a = in/co
_>Что это?

Это он типа s и a сократил...
Знаешь анек, где в школе программистов учитель писална достке sin x = 1/2 и просил найти x?

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

0>У меня есть гипотеза: все программисты проходят через период идеологического пуризма, когда кажется, что некая логически стройная и элегантная парадигма — это истинный путь, а остальное надо выбросить все на свалку истории. Ничего, с опытом проходит.

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

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

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

S>>Пардон. Следовало сформулировать так: картофелина — это подмножество мешка с картошкой?

_>Не плодим сущности.
_>Есть множество картофелин.
_>картофелина — это подмножество множества картофелин.
подмножеством может быть только множество. Так, множество, состоящее из одной картофелины из мешка — это подмножество множества всех картофелин в мешке.

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

S>Здравствуйте, samius, Вы писали:
S>>Милнер ссылается на работу C.Strachey 1967-го года с предположением что именно там впервые был предложен термин. Там же упоминаются параметрический и специальный виды полиморфизма. Про subtype polymorphism ничего не было. Как было на самом деле — не знаю.
S>Выглядит правдоподобно.
Если Милнер не врет, конечно первая страница второй абзац снизу (саму работу не читал, если что. Только удачно нагуглил.)

S>З.Ы. Весь разговор напоминает мне спор по материаловедению, который я как-то проиграл однокласснику во втором классе. Он обратился к ещё одному однокласснику, чтоб тот рассудил нас: "прикинь, Антон говорит, что металл — это тоже железо!!!".

S>Спор был спровоцирован вопросом про то, можно ли считать медь железом. Я всего лишь пытался объяснить, что и медь и железо являются металлами, но ни один из них не является друг другом. Увы — такая концепция слишком далеко выходила за рамки доступной одноклассникам классификации материалов.
В общем случае для второго класса нехарактерно владение таким уровнем классификации. В быту многие до пенсии (и после) называют все металлические предметы железяками.
Что удивительно, переход "картофелина — это подмножество" напрягает во мне лишь несостоявшегося математика. На бытовом уровне сам бы такое ляпнул и не поморщился бы.

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

_>>>Типы разные, повторно использую реализацию operator+. Тут ест полиморфизм?
ARK>>Где именно "тут"? Если речь про оператор +, то он полиморфен, да. Обрабатывает разные типы.
_>Повторно используется реализация оператор+. Этот оператор полиморфен. Повторное использование — это не полиморфизм. Где-то здесь противоречие.

Не каждое повторное использование является полиморфным. И наоборот. Это ортогональные вещи.

_>>>И еще приведение типов — полиморфизм?
ARK>>Приведение типов в мейнстримовых языках — это синтаксическая конструкция языка. К синтаксическим конструкциям термин "полиморфизм" неприменим, по крайней мере общепринятые определения этого не подразумевают.
ARK>>Если же взять, скажем, Eiffel, в котором все приведения типов — обычные функции, то там эти функции не полиморфны.
_>с++, конструкторы и операторы приведения operator int(). Как это разрешается во время синтаксического разбора, построения аст?

Я не смог распарсить вашу фразу "конструкторы и операторы приведения operator int()". Если речь про оператор приведения к int у какого-то конкретного типа, то этот оператор не полиморфен.
А какое отношение к семантике языка имеет синтаксический разбор и построение аст — это мне неведомо.

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

_>>>Полиморфизм — это обработка ...
_>>>Обработка разная, применяем разные операции — обламываемся на слове "обработка", дальнейшее уточнение не важно. Единственное число, не все возможные обработки, а конкретная.

ARK>>Вот видите, сколько появляется всяких разных слов (причем я до конца все равно не понял). А определение должно быть коротким, полным и непротиворечивым (по возможности). Определение полиморфизма из википедии очень хорошее и использует известные в CS термины.

_>полиморфизм — выполнение конкретной операции в зависимости от типа данных.
_>Забыл артикль the (конкретный)

int AddInt(int, int)
float AddFloat(float, float)

Поехали по второму кругу. Тип данных — int; для него вполне конкретная операция (с артиклем the) — AddInt. Тип данных — float; конкретная операция AddFloat. Согласно вашему определению, AddInt и AddFloat полиморфны.

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

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

_>>>>Типы разные, повторно использую реализацию operator+. Тут ест полиморфизм?
ARK>>>Где именно "тут"? Если речь про оператор +, то он полиморфен, да. Обрабатывает разные типы.
_>>Повторно используется реализация оператор+. Этот оператор полиморфен. Повторное использование — это не полиморфизм. Где-то здесь противоречие.

ARK>Не каждое повторное использование является полиморфным. И наоборот. Это ортогональные вещи.

Встречный вопрос а почему оператор+ полиморфен? Операция одна и та же, принимает одни и те же типы, включая this, реализация одна и та же. Где он изменчив/полиморфен? Изменчив из-за приведения типов?

ARK>Я не смог распарсить вашу фразу "конструкторы и операторы приведения operator int()". Если речь про оператор приведения к int у какого-то конкретного типа, то этот оператор не полиморфен.

class A { operator int() {} }
int i;
A a;
int x;
x = 1 + i;
x = i + a;

есть только одна единственная перегрузка оператор+(int,int)
Полиморфен ли оператор+?

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

_>Встречный вопрос а почему оператор+ полиморфен? Операция одна и та же, принимает одни и те же типы, включая this, реализация одна и та же. Где он изменчив/полиморфен? Изменчив из-за приведения типов?

Потому что он работает с разными типами (А и его наследники) и в общем случае результат его действия для разных типов аргументов — разный.

ARK>>Я не смог распарсить вашу фразу "конструкторы и операторы приведения operator int()". Если речь про оператор приведения к int у какого-то конкретного типа, то этот оператор не полиморфен.

_>

_>class A { operator int() {} }
_>int i;
_>A a;
_>int x;
_>x = 1 + i;
_>x = i + a;
_>

_>есть только одна единственная перегрузка оператор+(int,int)
_>Полиморфен ли оператор+?

Не полиморфен, он работает только с целыми числами. Фактически, ваш код полностью эквивалентен "x = i + Convert.ToInt(a)".

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

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

_>>Встречный вопрос а почему оператор+ полиморфен? Операция одна и та же, принимает одни и те же типы, включая this, реализация одна и та же. Где он изменчив/полиморфен? Изменчив из-за приведения типов?

ARK>Потому что он работает с разными типами (А и его наследники) и в общем случае результат его действия для разных типов аргументов — разный.

На результат могут повлиять только конкретные значения параметров. А типы на входе этой операции одни и те же, они не могут влиять на результат даже в общем случае. Переходим на следующий уровень — полиморфизм по значению. Может сразу перейдем к сопоставлению с образцом, ограниченной версии полиморфизма по значению.

_>>

_>>class A { operator int() {} }
_>>int i;
_>>A a;
_>>int x;
_>>x = 1 + i;
_>>x = i + a;
_>>

_>>есть только одна единственная перегрузка оператор+(int,int)
_>>Полиморфен ли оператор+?

ARK>Не полиморфен, он работает только с целыми числами.
Нет он работает и с типом А.
ARK>Фактически, ваш код полностью эквивалентен "x = i + Convert.ToInt(a)".
Фактически любой код эквивалентен машинным кодам.

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

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

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

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

S>>>Пардон. Следовало сформулировать так: картофелина — это подмножество мешка с картошкой?

_>>Не плодим сущности.
_>>Есть множество картофелин.
_>>картофелина — это подмножество множества картофелин.
S>подмножеством может быть только множество. Так, множество, состоящее из одной картофелины из мешка — это подмножество множества всех картофелин в мешке.

И так возвращаясь к сути. Множество состоящее из наследования — это подмножество полиморфизма?

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

I>Ты лучше не про медь, а про полимиорфизм и наследование и какая тут корректная картина мира.
Так уже всё рассказали в топике. Ссылка на всеобъемлющий пост Гапертона была приведена.

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

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

S>>подмножеством может быть только множество. Так, множество, состоящее из одной картофелины из мешка — это подмножество множества всех картофелин в мешке.

_>

_>И так возвращаясь к сути. Множество состоящее из наследования — это подмножество полиморфизма?
Нет.
Вынужден признать, что в русском переводе Пирса использована более сильная формулировка, чем в оригинале. Она и заставила меня думать что цитируемый текст близок к определению.
Русский текст

Термин полиморфизм обозначает семейство различных механизмов...

Английский

The term polymorphism refers to a range of language mechanisms that allow a single part of a program to be used with different types in different contexts.

Все-таки "refers" нельзя толковать как "обозначает". Это шишка переводчикам.

Т.е. у Пирса этот фрагмент текста не относится к определению, но и не называет подмножество механизмов самим полиморфизмом.
Итак, наследование имеет отношение к полиморфизму, как один из механизмов, позволяющий использовать одну часть программы с разными типами в разных контекстах.

Формулировки вариаций полиморфизма у Пирса более сильные.

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

Что-то скучно стало. Есть дела повеселее. Признаю свое поражение. За сим откланяюсь.

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

http://rsdn.ru/forum/philosophy/5134906.1

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

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

_DA>>http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
_DA>>http://rsdn.ru/forum/philosophy/2853873

V>За ссылочки спасибо. Особенно хорошо доставляет вторая.

V>А вообще я в растерянности. Народ прицепился к фразе "Полиморфизьм основывается на наследовании" и устроил дикий холивар на тему того, так это или не так?

Не совсем так. Прицепился я, но холивар случился на другие темы. Конкретно эту формулировку никто не защищает.

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

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

_>Что-то скучно стало. Есть дела повеселее. Признаю свое поражение. За сим откланяюсь.

Редкий поступок. Уважаю! Серьезно.

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

S>"Похоже" — это как-то не аргумент против определения в википедии.

Любое слово является аргументом против любого слова/группы слов/статьи в википедии.
Википедия — хреновый источник

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

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

S>>"Похоже" — это как-то не аргумент против определения в википедии.

Ф>Любое слово является аргументом против любого слова/группы слов/статьи в википедии.
Я хотел сказать что "похоже" — не убедительный для меня аргумент против определения в википедии. Если для вас он убедительный, то рад за вас.

Ф>Википедия — хреновый источник
Приведите нехреновый. Лучше с вашими критериями оценки качества источника, что бы можно было построить предметный разговор.

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

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

_DA>http://en.wikipedia.org/wiki/Polymorphism_(computer_science)
Я уже высказал свое мнение на счет этой статьи

_DA>http://rsdn.ru/forum/philosophy/2853873

Все строиться вокруг "переменной". Более теоретически чистые функциональные языки идут лесом. Это камень в огород такого определения полиморфизма.

Забавляет определение
Полиморфизм — это одинаковое или разное поведение для разных типов. Напрашивается упрощение: полиморфизм — это какое-то поведение для данных разных типов. Под такое упрощенное определение любое поведение. Хороший термин, всеобъемлющий.

Начинают притягивать это "модное определение" ко всему подряд и выясняется что почти любая конструкция языка это полиморфизм. Поэтому приходится уточнять что за полиморфизм. При этом выясняется что у этого уточнения есть свое определение, более точное. Наследование — это механизм полиморфизма, перегрузка функций — это тоже механизм полиморфизма, обобщеннное программирование(метапрограммирование) — это механизм полиморфизма, можете продолжить список.

Здравствуйте, Ромашка, Вы писали:

Р>Здравствуйте, samius, Вы писали:
S>>При единственной задаче софта "работать" — самое тупое решение, при котором софт будет работать, является оптимальным.

Р>Ты знаешь... я вот только что переписал с нуля софт, который народ писал четыре года. За две недели. Так вот, самое тупое решение которое работает, является оптимальным.

Недостаточно данных, что бы я мог это как-то комментировать.

S>>А когда у вашего софта наметятся другие задачи, тогда и обсудим, как на них скажутся глобальные переменные и MainForm.Instance.CurConfig.бла-бла.

Р>А вот задачи софта к культуре написания кода совершенно перпендикулярны. Вот ты, лично, при хорошей культуре разработки, любишь придумать на ровном месте огромную кучу лишних задач "на перспективу", хотя для конкретной задачи этого совершенно не нужно. В итоге получается такой клубок паттернов, в котором без поллитра фиг разберешься.
Я так не считаю, мой начальник (программист) так не считает. Во всяком случае уровень сложности и гибкости решений мы с ним обговариваем и он претензий ко мне в этом отношении не высказывал.
Откуда дровишки?

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

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

V>Полиморфизьм основывается на наследовании.
Строго говоря, это же не правда...
Вот, например в старом добром С были примеры вполне так себе полиморфных #define MAX( X, Y ) ( (X) > (Y) ? (X) : (Y) ) ну и вполне так себе полиморфная qsort...

Но это тут не главное. Главное тут, IMHO, другое.

V> А что от чего должно быть унаследовано определяется в самом начале, и потом перетряска дерева наследования — жуткий гемор. Получается так, что существенное решение принимается в самом начале, когда нет всей полноты информации.

Строго говоря, это вообще свойство проектирование такое. Ошибки в архитектуре самые трудноисправимые...

Собственно конкретно ООП там или инкапсуляция с полиморфизмом тут не при чём.
Это просто такое вот войство проетирования сложных систем. Тут это лечитя не ООП там или ещё каким ссеребрянным ятаганом, а путём инженерной школы, опыта там, головы, приложенной в нужное место нужным образом и всего такого...

А споры о том, что такое тру ООП, а что нет к этой РЕАЬНОЙ проблеме никакого отношения не имеют...

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

MS>Все это такое фуфло, я вас скажу эти ваши философии.

Всё в порядке, дружище, дыши глубже.

MS>Так же как и много других умных слов про программирование. На практике же, надо просто решать конкретную прикладную задачу, вот и все. И в результате оказывается, что умные программеры во всем коде на C# (!) во всю используют глобальные переменные! Как на старом добром Фортране — везде фигурирует MainForm.Instance.CurCofig.бла-бла. Ну и че? Это плохо? Нет — это нормально. Потому что софта работает и выполняет свою задачу.

Угу, это нормально.

MS>Ну это наверное мое личное мировосприятие — программирование является лишь вспомогательным инструментом для решения более серьезных задач, инженерного и научного типа.

Да, так и есть. Программы ценны только в контексте задач, ради которых они пишутся.

MS>И пофигу на весь этот ваш умный computer science, тем более, что иногда приходится объяснять, что поделить на 10 это не то же, что умножить на 0.1 — вот в чем заключается computer science, а не в том, что бы наследовать хрень от белиберды или наоборот.

Вся проблема в том, что "умные слова про программирование" — это побочная наукообразная ветка от дерева Computer Science. Так что, ты не смешивай одно с другим. Для примера погугли по словами Liskov Substitution Principle: как он звучит в оригинале и во что превращён "умными словами".

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

MS>везде фигурирует MainForm.Instance.CurCofig.бла-бла. Ну и че? Это плохо? Нет — это нормально.
Ну, если человек в инвалидном кресле с воткнутой капельницей в вену нормально, то да, ничего такого плохого.

Как по мне — это криво, потому что в конкретном месте кода моего класса мне нужен CurCofig. И мне фиолетово откуда от возьмется настолько, что я и знать этого не желаю.
Откуда он берется, вчера, сегодня, завтра, как его получить — это НЕ забота моего кода.
Если он конечно — здоров. Если болен — то конечно, нормально усадить в кресло с колесиками, воткнуть капельницу в руку, и на рот маску к кислородному баллону.

Мало того, все эти гирлянды:

get1().get2().get3().get4().get5()....

вызывают подозрение в мышлении постоянно пишущего такое. Конечно, для разового применения — допустимо. Но если в одном методе — дважды, то:
— это признак не понимания разницы между ЧТО и КАК. Или — безвкусица мышления.

достаточно упрятать эту гирлянду в отдельный метод, чтобы разделить это ЧТО мне нужно, от КАК получить это нечто

Особенно умиляет когда есть базовый класс, а во всех наследниках эти гирлянды.
Уж точно — наследники должны вызывать метод базового класса, в котором упрятано это КАК получить.

В том числе и для случая — MainForm.Instance.

Здравствуйте, samius, Вы писали:
S>Недостаточно данных, что бы я мог это как-то комментировать.

Ты опять усложняешь. Вывод очень простой — 90% (и это очень оптимистичная оценка) написанного программистами кода банально не нужны.

S>Я так не считаю, мой начальник (программист) так не считает. Во всяком случае уровень сложности и гибкости решений мы с ним обговариваем и он претензий ко мне в этом отношении не высказывал.
S>Откуда дровишки?

Земля шарик маленький. Еще раз, Samius, я хорошего мнения о тебе и о твоем коде. Речь не о красоте, сложности, гибкости или еще каких-либо метриках кода, речь о том, что этот код просто никому не нужен (кроме программиста и его начальства). Это, вообще говоря, проблема совсем не программистов — нам пофиг, пока деньги капают, мы пишем (чем больше пишем, тем дольше капают деньги).

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

Здравствуйте, Ромашка, Вы писали:

Р>Здравствуйте, samius, Вы писали:
S>>Недостаточно данных, что бы я мог это как-то комментировать.

Р>Ты опять усложняешь. Вывод очень простой — 90% (и это очень оптимистичная оценка) написанного программистами кода банально не нужны.
На счет 90 не знаю, но в принципе поддержу. Сам 8 лет своей жизни писал практически в стол. В то время как обычно код теряет актуальность не сразу, я писал в стол сразу и бесповоротно. Несколько лет понадобилось что бы это осмыслить и еще пару я пописал в стол просто по инерции.

Р>Земля шарик маленький. Еще раз, Samius, я хорошего мнения о тебе и о твоем коде. Речь не о красоте, сложности, гибкости или еще каких-либо метриках кода, речь о том, что этот код просто никому не нужен (кроме программиста и его начальства). Это, вообще говоря, проблема совсем не программистов — нам пофиг, пока деньги капают, мы пишем (чем больше пишем, тем дольше капают деньги).
Здесь я не соглашусь. Я могу писать лишнее потому как не понял задачу, или после написания изменилось видение пути решения. Но такого не было что бы мне дали деньги (зарплату) и сказали бы пиши и не думай, зачем это надо и кому сделает жизнь лучше. Конечно, если бы мне не платили зарплату, я бы занимался чем-то другим.

Р>ТС говорит о том, что если код нужен, всем плевать на то, макароны там или паттерны, а пользователи готовы мириться с умопомрачительным количеством глюков на квадратный килобайт кода. Ты говоришь о том, что нужно писать хороший код. Вы оба правы, вы просто о разном говорите.
На моей памяти довольно много нужного кода было отвергнуто по причине глюков, либо трудоемкости его развития.
А однажды именно глобальные переменные (и их обилие) привело к нехилому усложнению и удорожанию интеграционного тестирования. Я не хочу сказать что так должно быть с каждым проектом. Просто говно выстреливает. И чем актуальнее код, тем больнее прилетает. Это мой опыт.

Здравствуйте, jazzer, Вы писали:
J>Точно. Мало того, еще и одну из лучших векторных библиотек AGG написал. Гнать из профессии мокрыми тряпками.
Ну зачем же так. Я в позитивном ключе: у нас в стране философов меньше чем фотографов, а тут такой демагогический талант пропадает.

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

V>Для того, чтобы летать, нужны крылья. Это тоже полуправда. Потому что летать можно по-разному, с том числе и из окна вниз головой. Но когда есть крылья, летать получается проще и естественнее

Пингвина видел? А эму?

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

Мои извинения за задержку с ответом, много чет навалилось.

Со всем поскипаным согласен.

S>А однажды именно глобальные переменные (и их обилие) привело к нехилому усложнению и удорожанию интеграционного тестирования. Я не хочу сказать что так должно быть с каждым проектом. Просто говно выстреливает. И чем актуальнее код, тем больнее прилетает. Это мой опыт.

Оно всегда прилетит, чудес не бывает. Я не знаю, как это точно называется, я называю это слабо/сильно интегрированными системами. Слабо интегрированные системы это и есть лапша. Замечательный пример — 1Ц. Классический говонокод — вся логика на формах, глобальные переменные и прочие радости. Такой подход дает постоянную (по мере усложнения проекта) цену на добавление нового функционала и быстро растущую стоимость изменения системы. Понятно почему, попытка что-либо изменить приводит к необходимости переписать весь проект. В противоположность этому есть сильно интегрированные системы. Там стоимость добавления нового функционала растет по мере увеличения сложности, а стоимость изменения системы остается постоянной.

Так вот, стоимость написания нового кода в любом проекте рано или поздно превысит комфортный предел. Либо на добавление, либо на изменения. Мы можем только несколько отодвинуть этот момент. Причем я не уверен, что надолго.

Здравствуйте, Ромашка, Вы писали:

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

Р>Мои извинения за задержку с ответом, много чет навалилось.

Со всем поскипаным согласен.
Ничего страшного, куда спешить?

Р>Оно всегда прилетит, чудес не бывает.
Бывают чудеса в виде проектов в стиле "написал и забыл" при условии что длительность написания мала. Мы их не рассматриваем в контексте стоимости внесения изменений. Это не возражение, а так, уточнение.

Р>Я не знаю, как это точно называется, я называю это слабо/сильно интегрированными системами. Слабо интегрированные системы это и есть лапша. Замечательный пример — 1Ц. Классический говонокод — вся логика на формах, глобальные переменные и прочие радости. Такой подход дает постоянную (по мере усложнения проекта) цену на добавление нового функционала и быстро растущую стоимость изменения системы. Понятно почему, попытка что-либо изменить приводит к необходимости переписать весь проект. В противоположность этому есть сильно интегрированные системы. Там стоимость добавления нового функционала растет по мере увеличения сложности, а стоимость изменения системы остается постоянной.
Я понял, о чем речь. Предлагаю ввести понятие "направления изменений" и характеризовать системы адекватностью предполагаемым направлениям изменений.
Таким образом, названные тобой слабо интегрированные системы (логика на формах, глобальные переменные и прочие гадости), будут безобразно дешевы в плане добавления кнопки и изменения той самой логики обоработки кнопки, но затратны в плане превращения в веб-серис. Пока не грозит превращение в веб-сервис — кашляли мы на эти затраты.
Допустим, пописали мы систему год и увидели что риск внесения ошибок при изменении системы вырос до нежелательных величин. Выходы следующие: команда тестеров — дорого (это предположение, может и совсем не дорого), автоматизированное тестирование — дешево, но надо все переписать и потратить время на реализацию нефункциональных для заказчика вещей.
Ладно, переписали. Теперь все грамотно, логика в отдельном проекте, глобальных переменных нет (мешали тестировать... не знаю, кому как, а мне мешают), прикрутили MV"?", DI-контейнеры, и получили ад при добавлении кнопки на форму. Зато система на счет раз превращается в веб-серивс...

Р>Так вот, стоимость написания нового кода в любом проекте рано или поздно превысит комфортный предел. Либо на добавление, либо на изменения. Мы можем только несколько отодвинуть этот момент. Причем я не уверен, что надолго.
Рано или поздно потухнет солнце, но нас это не сильно беспокоит

По поводу комфортного предела — не соглашусь. Нет такого предела в его абсолютном значении, как и нет предела сложности системы. Есть вот такие вопросы и ответы на них:
* Что мы можем предпринять для того что бы вот такого рода изменения сделать комфортными на сколько это возможно?
* Какова будет цена этого комфорта?
* Что мешало (или не давало повода) подумать об этом на стадии комфортного изменения/переписывания всей системы?

Потом начинается новый проект, смотрим на вводную и думаем, где нужно подстелить по минимуму, что бы посередине проекта не пришлось бы его переписывать. И тогда находится коллега, который говорит:
— Чувак! Ты напереоверинженерил!
Да, возможно. И если бы я 4 года назад знал все текущие требования и удачные решения, возможно я бы и написал систему за пару месяцев в окончательном виде без комфорта при внесении внезапных изменений.
Но практика опять же показывает, что требования меняются даже у задач, которые нужно просто переписать, и казалось бы, все про них уже известно.

Эта зараза распространяется и на C++

Есть "программисты C++", которые думают что свободных функций нужно избегать, и тащить всё в классы

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

_>>>И так возвращаясь к сути. Множество состоящее из наследования — это подмножество полиморфизма?

A>>Наследование, само по себе, не является полиморфизмом. Наследование — это лишь механизм, позволяющий добиться динамического ad-hoc полиморфизма (по типу неявно передаваемого параметра this) в языках программирования, в который наследование имеет "subtyping" семантику (грубо говоря, разрешено приведение к базовому типу). Вполне возможен такой язык (причем, он будет OO языком), в котором есть наследование, но запрещено явное и неявное приведение к базовому классу (чтобы нельзя было нарушить LSP), а ОО-шный полиморфизм делается только на интерфейсах.
S>Более того, мы знаем такой язык. В нём достаточно написать class B: private A, как мы тут же потеряем способность передавать ссылки на B в произвольный код, ожидающий A. Т.е. наследование — есть, а полиморфизма — нету.

Всех тонкостей не помню, но в дружественной функции вроде можно кастовать к приватному базовому типу.

Что такое "наследование"?
Достаточно написать "class B: private A" и мы получаем агрегацию/композицию, а не наследование.

Для полноты картины: что такое инкапсуляция и полиморфизм?

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

_>Всех тонкостей не помню, но в дружественной функции вроде можно кастовать к приватному базовому типу.
Можем, да. Вот такой вот ограниченный получается полиморфизм.

_>Что такое "наследование"?
Наследование — это отношение is-a. В конкретных языках оно может быть реализовано несколько по-разному, но в целом обычно мы наблюдаем следующие черты:
1. Subtyping между родителем и наследником, следствием которого является совместимость по присваиванию ссылок и указателей.
2. Наследование состояния: каждый экземпляр потомка содержит в себе полное состояние предка (используется для обеспечения п.1)
3. Наследование поведения: все экземплярные методы предка работают и на потомке. Поведение статических методов и конструкторов зависит от вкусов дизайнеров языка; как правило, они не наследуются.
4. Полиморфизм экземплярных методов: потомок может переопределять некоторые методы предка, меняя их поведение.

_>Достаточно написать "class B: private A" и мы получаем агрегацию/композицию, а не наследование.
Вы бы всё же разобрались в основах. Всего четыре термина в ветке, а вы уже сорок постингов отказываетесь принять их общепринятые определения.
В частности, приватное наследование — это всё же наследование, а вовсе не агрегация.

_>Для полноты картины: что такое инкапсуляция и полиморфизм?
Инкапсуляция — возможность предоставлять различные контракты различному коду. В самом примитивном виде мы отличаем "внутренний" код от "внешнего" (секции interface и implementation в классическом Паскале или ); в более интересном виде мы можем отличать "код потомков данного класса в любой сборке", "код посторонних классов в данной сборке", и т.п.
Про полиморфизм всё уже сказано здесь: http://rsdn.ru/forum/philosophy/2853873

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

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

_>>Всех тонкостей не помню, но в дружественной функции вроде можно кастовать к приватному базовому типу.
S>Можем, да. Вот такой вот ограниченный получается полиморфизм.

А как же утверждение "полиморфизма нет"?

_>>Что такое "наследование"?
S>Наследование — это отношение is-a. В конкретных языках оно может быть реализовано несколько по-разному, но в целом обычно мы наблюдаем следующие черты:
S>1. Subtyping между родителем и наследником, следствием которого является совместимость по присваиванию ссылок и указателей.
S>2. Наследование состояния: каждый экземпляр потомка содержит в себе полное состояние предка (используется для обеспечения п.1)
S>3. Наследование поведения: все экземплярные методы предка работают и на потомке. Поведение статических методов и конструкторов зависит от вкусов дизайнеров языка; как правило, они не наследуются.
S>4. Полиморфизм экземплярных методов: потомок может переопределять некоторые методы предка, меняя их поведение.

_>>Достаточно написать "class B: private A" и мы получаем агрегацию/композицию, а не наследование.
S>Вы бы всё же разобрались в основах. Всего четыре термина в ветке, а вы уже сорок постингов отказываетесь принять их общепринятые определения.
S>В частности, приватное наследование — это всё же наследование, а вовсе не агрегация.

А как же "is-a"? А композиция/агрегирование, которое реализовано через приватное наследование, ближе к инкапсуляции, чем к наследованию.

_>>Для полноты картины: что такое инкапсуляция и полиморфизм?
S>Инкапсуляция — возможность предоставлять различные контракты различному коду. В самом примитивном виде мы отличаем "внутренний" код от "внешнего" (секции interface и implementation в классическом Паскале или ); в более интересном виде мы можем отличать "код потомков данного класса в любой сборке", "код посторонних классов в данной сборке", и т.п.

Какие контракты? Что за различный код? Мне кажется ты продвигаешь другую теорию под видом определений ООП.
Инкапсуляция — это ограничение доступа к внутренностям объекта из-вне, а еще объединение данных и алгоритмов обрабатывающих с этими данные.

S>Про полиморфизм всё уже сказано здесь: http://rsdn.ru/forum/philosophy/2853873

Хочу заметить что там сказано что наследование — это механизм параметрического полиморфизма, а предыдущий оратор пишет что это механизм ad-hoc полиморфизма. Кто-то врет.

Ad-hoc полиморфизм — это виртуальные функции, и наследование тут поскольку-постольку, можно другие механизмы использовать для виртуальных функций.

Признаю свое поражение. Перехожу в режим read only.

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

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

_>>Для полноты картины: что такое инкапсуляция и полиморфизм?
S>Инкапсуляция — возможность предоставлять различные контракты различному коду. В самом примитивном виде мы отличаем "внутренний" код от "внешнего" (секции interface и implementation в классическом Паскале или ); в более интересном виде мы можем отличать "код потомков данного класса в любой сборке", "код посторонних классов в данной сборке", и т.п.

Я бы сказал что инкапсуляция это сокрытие деталей в общем случае. Деталями может быть все что угодно от данных до способов, алгоритмов. Понятие инкапсуляции двойственно абстракции. Т.е. как только мы от чего-то абстрагировались, значит мы скрыли какую-то деталь.
* Слой аппаратных абстракций (HAL) скрывает (инкапсулирует) различия в аппаратном обеспечении;
* fopen/FILE инкапсулирует детали взаимодействия с файловой системой;
* std::vector<T> инкапсулирует особенности реализации абстрактного типа данных "динамический массив";
* template <...> void sort (RandomAccessIterator first, RandomAccessIterator last, Compare comp) инкапсулирует как метод сортировки, так и детали его реализации. Точно так же инкапсулируются сортируемые данные, способ их хранения и способ сравнения значений, но в обратном направлении. Т.е. эти особенности скрываются от реализации sort.
Таким образом, у нас в общем случае может не быть отличий "внутренний/внешний", как и модификаторов видимости. Инкапсуляция работает на уровне "знаем/не знаем" особенность.

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

_>Какие контракты? Что за различный код? Мне кажется ты продвигаешь другую теорию под видом определений ООП.
ООП не определяет эти термины, оно их только использует, причем строго ограниченную часть.

_>Инкапсуляция — это ограничение доступа к внутренностям объекта из-вне, а еще объединение данных и алгоритмов обрабатывающих с этими данные.
Ограничение доступа — частный случай. А к объединению данных и алгоритмов вообще никакого отношения. Алгоритмы могут быть разбросаны, это только увеличивает инкапсуляцию (http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197).

S>>Про полиморфизм всё уже сказано здесь: http://rsdn.ru/forum/philosophy/2853873
_>

_>Хочу заметить что там сказано что наследование — это механизм параметрического полиморфизма, а предыдущий оратор пишет что это механизм ad-hoc полиморфизма. Кто-то врет.
Наследование — это проявление ограниченного параметрического полиморфизма. Чистый параметрический полиморфизм работает для всех типов одинаково. А наследование позволяет использовать только типы, являющиеся наследниками (и то не всегда). Т.е. некоторые аспекты параметрического полиморфизма проявляются, но не вполне, значит относить наследование к параметрическому полиморфизму нельзя.

_>Ad-hoc полиморфизм — это виртуальные функции, и наследование тут поскольку-постольку, можно другие механизмы использовать для виртуальных функций.
Виртуальные функции — лишь частный случай ad-hoc полиморизма. Так же к нему относятся перегрузка операторов и функций, duck typing, late binding, multimethods (multiple dispatch), а так же подмножество pattern matching-а для некоторых языков.
И не для, а вместо. Под виртуальными функциями подразумевается вполне конкретный механизм.

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

_>А как же "is-a"? А композиция/агрегирование, которое реализовано через приватное наследование, ближе к инкапсуляции, чем к наследованию.

Композицию и агрегирование можно реализовать в том числе и через наследование. Более того, это можно реализовать вообще не используя ни наследование, ни инкапсуляцию и тем не менее будет композиция и агрегирование.

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

_>Достаточно написать "class B: private A" и мы получаем агрегацию/композицию, а не наследование.

Ну да, как же. Посмотри в сторону вирутальных деструкторов, например. За Приватную базу объектом владеть таки можно, а через поле, хоят бы и публичное -- нет. Так что получаем, что в С++ наследование и инкапсуляция никак не связаны. Можно быть чьим-то наследником, но скрывать это, например. Или скрывать это от всех, кроме своих наследников и друзей, как вариант

Вообще надо понимать, что С++ наследование и ООП наследование -- это разные понятия. Есть такая версия ООП, где подразумевается некоторая можель наследования. Думаю она тебе известна. И она ближе всего к публичному виртуальному наследованию в С++.
А вот в С++ наследование -- это один из мезанизмов организации данных, и ассоциированного с ними кода. И используется в С++ наследование очень много для чего, а не только для можелирования того самого приООПешного наследования...

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

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

S>>>Про полиморфизм всё уже сказано здесь: http://rsdn.ru/forum/philosophy/2853873
_>>

_>>Хочу заметить что там сказано что наследование — это механизм параметрического полиморфизма, а предыдущий оратор пишет что это механизм ad-hoc полиморфизма. Кто-то врет.
A>Давай на примере объясню.
A>Дано:

пример не наследования а перегрузки (override). А что такое перегрузка функций? Подсказка, это не параметрический полиморфизм.

Вот пример наследования и параметрического полиморфизма:
class A { add(A) }
class B : A
class C : A

a.add(a)
b.add(b)
c.add(c)

A>В этом смысле наследование это "механизм параметрического полиморфизма" — оно нужно чтобы иметь возможность писать такие вот параметрически полиморфные методы; без такой возможности оно нафиг не нужно.
Ничегонепонял, но ты прав.

Вроде, тебе я еще не сдавался. Сдаюсь.

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

_>>Что такое "наследование"?
S>Наследование — это отношение is-a.
К сожалению на определение — это не тянет.
если я напишу class Man: Fish {} — это наследование или нет??

S>В конкретных языках оно может быть реализовано несколько по-разному, но в целом обычно мы наблюдаем следующие черты:
выделение убивает ценность этих пунктов напрочь.
S>1. Subtyping между родителем и наследником, следствием которого является совместимость по присваиванию ссылок и указателей.
S>2. Наследование состояния: каждый экземпляр потомка содержит в себе полное состояние предка (используется для обеспечения п.1)
S>3. Наследование поведения: все экземплярные методы предка работают и на потомке. Поведение статических методов и конструкторов зависит от вкусов дизайнеров языка; как правило, они не наследуются.
S>4. Полиморфизм экземплярных методов: потомок может переопределять некоторые методы предка, меняя их поведение.

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

_>пример не наследования а перегрузки (override).
overload — перегрузка, override — переопределение
_>А что такое перегрузка функций? Подсказка, это не параметрический полиморфизм.
Перегрузка (которая overload) по типу параметров — статический ad-hoc полиморфизм

_>Вот пример наследования и параметрического полиморфизма:
_>class A { add(A) }
_>class B : A
_>class C : A

_>a.add(a)
_>b.add(b)
_>c.add(c)
Тут да, метод add параметрически полиморфен по обоим параметрам.

Здравствуйте, fin_81, Вы писали:
_>А как же утверждение "полиморфизма нет"?
Снаружи — нет.

_>А как же "is-a"? А композиция/агрегирование, которое реализовано через приватное наследование, ближе к инкапсуляции, чем к наследованию.
Я же написал, как именно.

_>Какие контракты? Что за различный код? Мне кажется ты продвигаешь другую теорию под видом определений ООП.
_>Инкапсуляция — это ограничение доступа к внутренностям объекта из-вне, а еще объединение данных и алгоритмов обрабатывающих с этими данные.
Я просто смотрю правде в глаза. Чтобы приблизить ваше понимание инкапсуляции к настоящему, нужно дать себе труд задуматься о том, что такое "внутренности" и что такое "извне". Внезапно окажется, что реальное программирование оперирует не чёрно-белым миром private/public, а значительно более интересными градациями.

_>Хочу заметить что там сказано что наследование — это механизм параметрического полиморфизма, а предыдущий оратор пишет что это механизм ad-hoc полиморфизма. Кто-то врет.
Нет, кто-то не понимает. Чтобы осмысленно обсуждать тему, нужно разбираться, какое значение имеет каждое слово.
Если вы пишете (обычный!) метод, который принимает в качестве аргумента ссылку на A, то получаем параметрический полиморфизм. Понятно, почему, или надо разжёвывать?
Когда вы перегружаете виртуальный метод, то получаете ad-hoc полиморфизм. Понятно, почему, или надо разжёвывать?

_>Ad-hoc полиморфизм — это виртуальные функции, и наследование тут поскольку-постольку, можно другие механизмы использовать для виртуальных функций.
Виртуальные функции — это как раз механизм. А наследование — это концепция. То, что вы называете "другие механизмы", скорее всего, виртуальными функциями не является.

_>Признаю свое поражение. Перехожу в режим read only.
Давно пора.

Здравствуйте, samius, Вы писали:
S>Я бы сказал что инкапсуляция это сокрытие деталей в общем случае. Деталями может быть все что угодно от данных до способов, алгоритмов. Понятие инкапсуляции двойственно абстракции. Т.е. как только мы от чего-то абстрагировались, значит мы скрыли какую-то деталь.
S>* Слой аппаратных абстракций (HAL) скрывает (инкапсулирует) различия в аппаратном обеспечении;
S>* fopen/FILE инкапсулирует детали взаимодействия с файловой системой;
S>* std::vector<T> инкапсулирует особенности реализации абстрактного типа данных "динамический массив";
S>* template <...> void sort (RandomAccessIterator first, RandomAccessIterator last, Compare comp) инкапсулирует как метод сортировки, так и детали его реализации. Точно так же инкапсулируются сортируемые данные, способ их хранения и способ сравнения значений, но в обратном направлении. Т.е. эти особенности скрываются от реализации sort.
S>Таким образом, у нас в общем случае может не быть отличий "внутренний/внешний", как и модификаторов видимости. Инкапсуляция работает на уровне "знаем/не знаем" особенность.
Детали — это некий контракт. Инкапсуляция как сокрытие означает, что кусок кода номер 1 "видит" не то, что кусок кода номер 2.
Всё, что "видит" код — это некий контракт.
С точки зрения метода Method1 объект типа А оборудован единственным методом ToString(). А с точки зрения метода Method2() у объекта типа А есть ещё и куча полей, методов, и прочих штук. При этом компилятор всё ещё проверяет соответствие использования объектов класса A в коде Method2 некоторому контракту. Какому именно — зависит от того, где объявлен этот Method2 — в самом классе A, в классе, унаследованном от класса A, в той же сборке, что и класс A, и так далее.
Если мы не можем отличить, является ли код внутренним или внешним, то компилятор не сможет проверить корректность использования контрактов — а, стало быть, никакой инкапсуляции не получится.

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

J>К сожалению на определение — это не тянет.

J>если я напишу class Man: Fish {} — это наследование или нет??
Наследование. А что вас не устраивает?

S>>В конкретных языках оно может быть реализовано несколько по-разному, но в целом обычно мы наблюдаем следующие черты:
J>выделение убивает ценность этих пунктов напрочь.
У вас есть какое-то более другое определение?

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

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

J>>К сожалению на определение — это не тянет.
S>

J>>если я напишу class Man: Fish {} — это наследование или нет??
S>Наследование. А что вас не устраивает?
тем, что Man is NOT a fish.

S>>>В конкретных языках оно может быть реализовано несколько по-разному, но в целом обычно мы наблюдаем следующие черты:
J>>выделение убивает ценность этих пунктов напрочь.
S>У вас есть какое-то более другое определение?

если бы было, я б в эту ветку встревал. Максимум что я могу придумать, что наследование — это элемент синтаксиса. ну вот сказал Хейлсберг: "В C# если MyChild определен как 'class MyChild: MyParent', то будем говорить, что MyChild наследуется от MyParent" — вот и появилось в C# наследование. А если б Хейсберг сказал "..., то будем говорить, что MyChild куксится от MyParent" — было в C# куксение, а наследования не было. А отношение is a — не в тему, оно в мозгу программиста сидит, а не в ЯП. И реализовать его можно вагоном разных способов реализовать, ну там, перекрыть оператор неявного приведения типов, например.

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

J>если бы было, я б в эту ветку НЕ встревал.

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

S>Здравствуйте, samius, Вы писали:
S>>Таким образом, у нас в общем случае может не быть отличий "внутренний/внешний", как и модификаторов видимости. Инкапсуляция работает на уровне "знаем/не знаем" особенность.
S>Детали — это некий контракт. Инкапсуляция как сокрытие означает, что кусок кода номер 1 "видит" не то, что кусок кода номер 2.
"Видит" — это немного не то. Вот допустим что мой код видит (и может безболезненно для компиляции использовать) безобразное количество идентификаторов, начинающихся с _, __. Так вот, инкапсуляция начинается там где приходит понимание того факта, что если я не хочу обнаружить непредсказуемое поведение вызываемого мной кода, или не хочу переписывать код при обновлении библиотеки, я не должен юзать эти идентификаторы.
Вместе с тем, модификаторы доступа ограничивают не видимость, а именно доступ.

S>Всё, что "видит" код — это некий контракт.
Изначально контракт — это все что документировано. А разметка модификаторами доступа, как и другие способы управления видимостью — это только делегирование компилятору проверки соответствия контракту, защита от Буратин, не читающих документацию.
Позже при отсутствии документации мы стали пытаться восстанавливать контракт по видимым/публичным артефактам. Но это вовсе не значит что обнаружив публичный метод с названием __не_вызывай_меня_никогда_все_сломается___совсем(), следует его первым делом вызвать.

S>С точки зрения метода Method1 объект типа А оборудован единственным методом ToString(). А с точки зрения метода Method2() у объекта типа А есть ещё и куча полей, методов, и прочих штук. При этом компилятор всё ещё проверяет соответствие использования объектов класса A в коде Method2 некоторому контракту. Какому именно — зависит от того, где объявлен этот Method2 — в самом классе A, в классе, унаследованном от класса A, в той же сборке, что и класс A, и так далее.
S>Если мы не можем отличить, является ли код внутренним или внешним, то компилятор не сможет проверить корректность использования контрактов — а, стало быть, никакой инкапсуляции не получится.
Проверка компилятором корректности использования контрактов вторична. Вот возьмем тот же WinAPI. Контракты есть, а модификаторов нет. И компилятор не ограничивает нас от того что бы послать любое сообщение любому Handle-у. Кто скажет что в WinAPI нет инкапсуляции?

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

S>>В общем случае для второго класса нехарактерно владение таким уровнем классификации. В быту многие до пенсии (и после) называют все металлические предметы железяками.
S>Это понятно. Непонятно такое же невладение на профессиональном форуме.
S>Ну, то есть оно, наверное, объяснимо — какие-то негодяи тридцать лет внедряли мисконцепцию "ООП = инкапсуляция, наследование, полиморфизм", что привело к смешенью умов. Но всё равно вызывает разочарование как само невладение, так и отказ воспринимать корректную картину мира.

Ну, дык, был спор про парадигмы когда-то... Установили, что ООП — это "всего лишь" парадигма. А парадигма — это некая совокупность устоявшихся практических подходов к решению задач + инструментарий, всё вместе образующие "культуру дизайна в рамках ХХХ", "взгляд на проблему" и прочие плохо формулируемые вещи. Характерно, что в том споре никто не набирался смелости утверждать (как здесь), что составляющие этой "совокупности" могут входить только в одну парадигму.

З.Ы. Да и вообще... давно пора составить каталог ссылок на обсуждения прошлых лет здесь и стрелять ими сразу же в ответ... Бо на качественное обсуждение, смотрю, ни у кого давно не "стоит". ((

Здравствуйте, Jack128, Вы писали:
S>>Наследование. А что вас не устраивает?
J>тем, что Man is NOT a fish.
Непонятно, откуда вы это взяли. В том языке, где вы можете так написать, Man вполне себе a Fish.

J>если бы было, я б в эту ветку встревал. Максимум что я могу придумать, что наследование — это элемент синтаксиса. ну вот сказал Хейлсберг: "В C# если MyChild определен как 'class MyChild: MyParent', то будем говорить, что MyChild наследуется от MyParent" — вот и появилось в C# наследование.
Лично мне ближе семантика, а не синтаксис.

А если б Хейсберг сказал "..., то будем говорить, что MyChild куксится от MyParent" — было в C# куксение, а наследования не было. А отношение is a — не в тему, оно в мозгу программиста сидит, а не в ЯП. И реализовать его можно вагоном разных способов реализовать, ну там, перекрыть оператор неявного приведения типов, например.
Имхо, у вас в голове какая-то каша.
is-a, в общефилософском смысле, выражается исключительно в виде LSP.
Когда мы рассматриваем LSP в конкретном языке программирования, абстрактный принцип превращается в конкретные утверждения. Типа "объект класса B можно передать в любой метод, принимающий аргументы класса A".

И вот если оказывается, что "куксение" реализует LSP, то мы говорим, что "в C# куксение является разновидностью ООП-шного наследования".

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

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

S>>Здравствуйте, samius, Вы писали:
S>>>Таким образом, у нас в общем случае может не быть отличий "внутренний/внешний", как и модификаторов видимости. Инкапсуляция работает на уровне "знаем/не знаем" особенность.
S>>Детали — это некий контракт. Инкапсуляция как сокрытие означает, что кусок кода номер 1 "видит" не то, что кусок кода номер 2.
S>"Видит" — это немного не то. Вот допустим что мой код видит (и может безболезненно для компиляции использовать) безобразное количество идентификаторов, начинающихся с _, __. Так вот, инкапсуляция начинается там где приходит понимание того факта, что если я не хочу обнаружить непредсказуемое поведение вызываемого мной кода, или не хочу переписывать код при обновлении библиотеки, я не должен юзать эти идентификаторы.
S>Вместе с тем, модификаторы доступа ограничивают не видимость, а именно доступ.
Это понятно. Инкапсуляция — это, конечно же, явление, а не механизм. Однако когда мы говорим о поддержке инкапсуляции в языке, мы ожидаем от компилятора проверки всех этих "я не должен".

S>Изначально контракт — это все что документировано. А разметка модификаторами доступа, как и другие способы управления видимостью — это только делегирование компилятору проверки соответствия контракту, защита от Буратин, не читающих документацию.
Лично моя точка зрения — в том, что в контексте языков программирования рассматривать документацию бессмысленно. С точки зрения документации, все языки обладают одинаковой выразительной силой. Интересны те контракты, которые можно выразить в языке — всё точно так же, как с инкапсуляцией. Контракт как явление существует независимо от языка, но поддержка контрактов всё же требуется.

S>Позже при отсутствии документации мы стали пытаться восстанавливать контракт по видимым/публичным артефактам. Но это вовсе не значит что обнаружив публичный метод с названием __не_вызывай_меня_никогда_все_сломается___совсем(), следует его первым делом вызвать.

Названия методов — ни о чём. Также как и аргумент с именем pleaseDontPassNullHere.

S>Проверка компилятором корректности использования контрактов вторична. Вот возьмем тот же WinAPI. Контракты есть, а модификаторов нет. И компилятор не ограничивает нас от того что бы послать любое сообщение любому Handle-у. Кто скажет что в WinAPI нет инкапсуляции?
Инкапсуляция там — в том, что вы не можете напрямую работать с внутренним состоянием контрола. Контракт, выраженный в терминах WinAPI, у всех контролов ровно один — SendMessage().
То, что контролы ведут себя существенно по разному в ответ на разные значения аргументов этого единственного метода "сделайВсё" — это недостаток выразительности в выбранном языке/платформе.
Неспроста первое, что делают все ООП-шные UI фреймворки под винапи — это определяют иерархию классов с методами, чтобы отойти от нетимизированного и непроверяемого SendMessage().

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

S>is-a, в общефилософском смысле, выражается исключительно в виде LSP.
S>Когда мы рассматриваем LSP в конкретном языке программирования, абстрактный принцип превращается в конкретные утверждения. Типа "объект класса B можно передать в любой метод, принимающий аргументы класса A".
ну вот мне эти конкретные утверждения и нужны.
Если я перекрою неявное преобразование типов из B в A, то экземпляр B можно будет передать в любой метод, принимающий A. Значит ли это, что B — наследник A ??? Если нет, то почему?

Здравствуйте, Jack128, Вы писали:
J>Если я перекрою неявное преобразование типов из B в A, то экземпляр B можно будет передать в любой метод, принимающий A. Значит ли это, что B — наследник A ??? Если нет, то почему?
Нет, так будет сделать нельзя. Потому что вы не сможете передать экземпляр B в любой метод, принимающий A. Вы по-прежнему будете передавать в метод экземпляр А.
Впрочем, язык, о котором вы говорите, разрабатывали не идиоты.
Попробуйте "перекрыть неявное преобразование" и подставить экземпляр B вместо A:

class A
{
   private int _a;
   public virtual void SetA(int a) { _a = a; }
   public virtual int  GetA() { return _a;}
}

void AnyMethod(A& param) // вот вам "любой" метод ;)
{
  param.SetA(42);
  cout << param.GetA();
}

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

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

S>>"Видит" — это немного не то...
S>>Вместе с тем, модификаторы доступа ограничивают не видимость, а именно доступ.
S>Это понятно. Инкапсуляция — это, конечно же, явление, а не механизм. Однако когда мы говорим о поддержке инкапсуляции в языке, мы ожидаем от компилятора проверки всех этих "я не должен".
Согласен. Когда мы говорим об инкапсуляции в языке мы почемуто подразумеваем разметку доступа членов класса и совершенно упускаем interface/implementation, *.h/*.c, PImpl и другие вещи.

S>Лично моя точка зрения — в том, что в контексте языков программирования рассматривать документацию бессмысленно. С точки зрения документации, все языки обладают одинаковой выразительной силой. Интересны те контракты, которые можно выразить в языке — всё точно так же, как с инкапсуляцией. Контракт как явление существует независимо от языка, но поддержка контрактов всё же требуется.
С тем что модификаторы внесли дополнительное средство выразительности и имеют отношение к самодокументации — я согласен.

S>>Позже при отсутствии документации мы стали пытаться восстанавливать контракт по видимым/публичным артефактам. Но это вовсе не значит что обнаружив публичный метод с названием __не_вызывай_меня_никогда_все_сломается___совсем(), следует его первым делом вызвать.

S>Названия методов — ни о чём. Также как и аргумент с именем pleaseDontPassNullHere.
В отношении инкапсуляции разница между модификатором видимости и соглашением по именованию членов лишь в том, что модификаторы видит компилятор и проверяет правомерность обращения к членам. В отношении скрываемых деталей ничего не изменяется.

S>>Проверка компилятором корректности использования контрактов вторична. Вот возьмем тот же WinAPI. Контракты есть, а модификаторов нет. И компилятор не ограничивает нас от того что бы послать любое сообщение любому Handle-у. Кто скажет что в WinAPI нет инкапсуляции?
S>Инкапсуляция там — в том, что вы не можете напрямую работать с внутренним состоянием контрола. Контракт, выраженный в терминах WinAPI, у всех контролов ровно один — SendMessage().
Я привел WinAPI лишь как пример наличия инкапсуляции при отсутствии проверок видимости компилятором.

S>То, что контролы ведут себя существенно по разному в ответ на разные значения аргументов этого единственного метода "сделайВсё" — это недостаток выразительности в выбранном языке/платформе.
S>Неспроста первое, что делают все ООП-шные UI фреймворки под винапи — это определяют иерархию классов с методами, чтобы отойти от нетимизированного и непроверяемого SendMessage().
Да, при этом выразительность повышается, а инкапсуляция, как правило, уменьшается. Не хочу сказать что предпочитаю WinAPI. Просто наблюдение.

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

K>из "Чистый код" Р. Мартина (гл. 3, "Функции"):

K>

K>Структурное программирование

K>Хотя мы с симпатией относимся к целям и методам структурного программирования, в очень компактных функциях эти правила не приносят особой пользы. Только при увеличении объема функций их соблюдение обеспечивает существенный эффект.

самое смешное, что уважаемый Р. Мартин испытывает симпатию к идеям Дейкстры совершенно их не понимая

Идея-то не в том, что от гото избавится без вариантов, а в том, что мы в любом месте кода можем написать слабейшее предусловие того, что программа будет успешна. То есть, попросту говоря, assert...

Дорогой Erop, Вы писали:

E>самое смешное, что уважаемый Р. Мартин испытывает симпатию к идеям Дейкстры совершенно их не понимая

E>Идея-то не в том, что от гото избавится без вариантов, а в том, что мы в любом месте кода можем написать слабейшее предусловие того, что программа будет успешна. То есть, попросту говоря, assert...

Из каких приведенных мною слов Р. Мартина вы заключили, что он их понимает идеи Дейкстры? И где он пишет о том, что от гото избавится нет вариантов?

K>Из каких приведенных мною слов Р. Мартина вы заключили, что он их не понимает идеи Дейкстры? И где он пишет о том, что от гото избавится нет вариантов?

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

K>Из каких приведенных мною слов Р. Мартина вы заключили, что он их понимает идеи
Ну он там типа пересказывает "идеи Дейкстры", при этом говорит вообще не о том о чём идеи

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

E>Ну он там типа пересказывает "идеи Дейкстры", при этом говорит вообще не о том о чём идеи

Он описание идеи вроде бы не затрагивал, подразумевая, что читатель знаком с ней.
И вроде бы он ясно пишет то, что хотел сказать:
— множественные return \ break \ continue усложняют чтение кода в большой функции, но в компактной функции вариант без множественного return может быть менее выразительным (а Р.Мартин рекомендует писать очень компактные функции, и обосновывает почему, в нескольких главах этой книги)
Пример (хоть и используется java, но будем считать что мы не знаем о конструкции ?:, это ведь всего лишь пример, который первым пришел в голову).

множественные return

int max(int first, int second) {
    if (first > second) {
        return first;
    } else {
        return second;
    }
}

одна точка выхода

int max(int first, int second) {
    int result;
    if (first > second) {
        result = first;
    } else {
        result = second;
    }
    return result;
}

— про goto он пишет, что если кто-то и решит использовать goto в своей программе, то желание использовать goto может возникнуть только в некомпактной функции, а раз к этому моменту Р.Мартин убедил читателя его книги в том, что нужно писать очень компактные функции, то вопрос об использовании goto и не поднимается. Ведь и вправду, зачем использовать goto в функции объемом 3-5 строчек...

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

K>- множественные return \ break \ continue усложняют чтение кода в большой функции, но в компактной функции вариант без множественного return может быть менее выразительным (а Р.Мартин рекомендует писать очень компактные функции, и обосновывает почему, в нескольких главах этой книги)

положим это не всегда хорошо. Ну да фиг бы с ним, не о том разговор же.
Я же конкретнонаписал, что смешно:

Хотя мы с симпатией относимся к целям и методам структурного программирования, в очень компактных функциях эти правила не приносят особой пользы. Только при увеличении объема функций их соблюдение обеспечивает существенный эффект

А структурное программирование оно не про конретную функцию, оно про программу в целом. И эффект приносит и в программе оформленной в виде больших функций и в программе обормленной в виде маленьких...

K>множественные return
K>

K>int max(int first, int second) {
K>    if (first > second) {
K>        return first;
K>    } else {
K>        return second;
K>    }
K>}
K>

Ну и это совершенно процедурный и доказуемый код...

Ты тут что конкретно не можешь написать? Постусловие? слабейшее предусловие всей функции? Или какого-то места в функции?

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

S>Здравствуйте, Jack128, Вы писали:
J>>Если я перекрою неявное преобразование типов из B в A, то экземпляр B можно будет передать в любой метод, принимающий A. Значит ли это, что B — наследник A ??? Если нет, то почему?
S>Нет, так будет сделать нельзя. Потому что вы не сможете передать экземпляр B в любой метод, принимающий A. Вы по-прежнему будете передавать в метод экземпляр А.

A a = CreateA(); // мы не знаем как реализована CreateA
по каким признакам я могу понять, что a — это экземпляр B? Только без рефлексии, пожалуйста.

S>Впрочем, язык, о котором вы говорите, разрабатывали не идиоты.
Ну мало какие языки на свете есть. Представим условную джаву с перегрузкой преобразования типов, но без ссылок.

Здравствуйте, Ромашка, Вы писали:

Р>Оно всегда прилетит, чудес не бывает. Я не знаю, как это точно называется, я называю это слабо/сильно интегрированными системами. Слабо интегрированные системы это и есть лапша. Замечательный пример — 1Ц. Классический говонокод — вся логика на формах, глобальные переменные и прочие радости. Такой подход дает постоянную (по мере усложнения проекта) цену на добавление нового функционала и быстро растущую стоимость изменения системы. Понятно почему, попытка что-либо изменить приводит к необходимости переписать весь проект. В противоположность этому есть сильно интегрированные системы. Там стоимость добавления нового функционала растет по мере увеличения сложности, а стоимость изменения системы остается постоянной.

Интересная техника — "Такой подход дает постоянную (по мере усложнения проекта) цену на добавление нового функционала и быстро растущую стоимость изменения системы."

Цена изменений вроде постоянная, а стоимость изменений растёт

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

J>A a = CreateA(); // мы не знаем как реализована CreateA
J>по каким признакам я могу понять, что a — это экземпляр B? Только без рефлексии, пожалуйста.
Не понимаю вопроса. Всё зависит от того, какой язык мы рассматриваем.
В С++ а — экземпляр A, а вовсе не B, как бы там ни была реализована CreateA().
В C# в а может оказаться ссылка на экземпляр типа, не совпадающего с A, только в том случае, если этот тип является подтипом A. Я навскидку знаю пять способов объявления A и устройства CreateA, которые позволяют получить в a что-то другого типа (не A), но ни один из них не относится к оператору преобразования типов.

Так что я по-прежнему не вижу способа ввести отношения is-a при помощи оператора неявного преобразования.

S>>Впрочем, язык, о котором вы говорите, разрабатывали не идиоты.
J>Ну мало какие языки на свете есть. Представим условную джаву с перегрузкой преобразования типов, но без ссылок.
Давайте представим, хотя ООП без ссылок не имеет физического смысла.
Покажите мне этот пример на вашей воображаемой джаве.

От:	McSeem2	http://www.antigrain.com
Дата:	10.04.13 18:00
Оценка:	33 (2) +3 -5

	От:	Baudolino
	Дата:	11.04.13 08:24
	Оценка:	+2 -1

От:	samius	http://sams-tricks.blogspot.com
Дата:	11.04.13 10:29
Оценка:	5 (1) +4

	От:	Abyx
	Дата:	11.04.13 10:43
	Оценка:	+4

От:	Sinclair	https://github.com/evilguest/
Дата:	15.04.13 17:19
Оценка:	+4

От:	Qbit86	https://twitter.com/qbit86
Дата:	10.04.13 18:03
Оценка:	+2

От:	Географ	нет
Дата:	10.04.13 18:14
Оценка:	+1

От:	jazzer	Skype: enerjazzer
Дата:	11.04.13 12:04
Оценка:	+1

От:	Mystic	http://mystic2000.newmail.ru
Дата:	11.04.13 18:54
Оценка:	+1

От:	Voblin	http://maslyaew.narod.ru/
Дата:	12.04.13 10:58
Оценка:

	От:	Ромашка
	Дата:	12.04.13 18:58
	Оценка:	+1

От:	D. Mon	http://thedeemon.livejournal.com
Дата:	11.04.13 11:27
Оценка:

От:	dimgel	https://github.com/dimgel
Дата:	11.04.13 12:21
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	12.04.13 08:16
Оценка:

От:	Философ	http://vk.com/id10256428
Дата:	12.04.13 17:12
Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	13.04.13 01:36
Оценка:

От:	Skynin	skynin.blogspot.com
Дата:	13.04.13 07:33
Оценка:

	От:	Evgeny.Panasyuk
	Дата:	16.04.13 15:37
	Оценка:

От:	MTD	https://github.com/mtrempoltsev
Дата:	20.04.13 11:58
Оценка: