Обсуждение:Полиморфизм (информатика)

message: Русская статья была неприемлемо погана, и содержала больше заблуждений, чем фактов, в связи с чем целиком заменена на эквивалентный перевод английского варианта, куда более объективного и вменяемого. Сделано лишь несколько мелких добавлений с примерами (в надежде пресечь повторный вандализм с внедрением заблуждений): абзац во вводной части, корректирующий аморфную строчку из старого варианта статьи, и расширение соотнесения обобщённого программирования с параметрическим полиморфизмом.
Запрашиваю немедленное утверждение статьи, пока вновь не испоганили.
Примечания для ООПшников:
* Кратко, но понятно, про отличие перегрузки от полиморфизма читать Харпера "Введение в Стандартный ML".
* Рассматривать формы полиморфизма внутри парадигм некорректно: полиморфизм - это свойство системы типов, которая, в свою очередь, является основой семантики языка (в статью добавлено). Это значит, что один и тот же вид полиморфизма можно реализовать в разных языках, но к уже разработанному языку добавить поддержку других форм полиморфизма можно далеко не всегда, не изменив язык до неузнаваемости. Например, в объектную модель Симулы невозможно ввести понятие переменной типа (type variable); в Питоне, хоть и есть наследование классов, в 99% случаев без него можно спокойно обойтись (причём выигрыв в гибкости, а не проиграв); в Хаскеле стремление предоставить одновременно полиморфизм и перегрузку привело к необходимости введения принципиально нового понятия - классов типов, из-за чрезмерного использования которых механизм выведения типа порой захлёбывается (примеры также помещены в статью).
* Термин "ad hoc polimorphism" некорректно переводить как "специальный". Слово "специальный" несёт в себе скрытое субъективное восхваление: мол, "общепринятое средство здесь оказалось недостаточно хорошо, поэтому было сделано средство лучше, но с более узкой сферой применимости". Эмуляция полиморфизма посредством перегрузки при наследовании этой характеристике не отвечает ни на йоту - хвалить C++/Delphi/Java будут только те, кто не работал в языках, типизированных по Хиндли-Милнеру или хотя бы динамически типизируемых. В Хаскеле даже перегруженные операторы остаются в первую очередь полиморфными. Корректными переводами "ad hoc" будут "спонтанный", "ситуативный", "сделанный на коленке".
* "истинным полиморфизмом" называют только тот, в котором физически *ОДИН* экземпляр функции в скомпилированном файле работает с бесконечным множеством типов данных (термин "чистый полиморфизм", в общем, тождественен, но не встречается). Как только появилась вторая функция, пусть даже "уточняющая" поведение для подтипа - полиморфизм перестаёт быть труЪ, т.к. согласованность поведения этих функций оказывается на совести программиста, а значит, человеческий фактор вторгается в формальную систему, как слон в посудную лавку.
* про множественное наследование, особенно виртуальное, здесь лучше не писать. Эта фигня, за которую надо как минимум убивать, не имеет под собой никакой формальной базы (т.е. если вести проектирование применением адекватного мат.аппарата, то к нему никогда и ни при каких условиях невозможно подойти) и присутствует только в уродце С++, там пусть и рассматривается. И не надо думать, что в Java и тем более CLOS то же самое - разница колоссальная, см. банально теорию множеств, и в частности теорию типов. Если же найдутся вменяемые лисперы, хорошо знающие одновременно CLOS и С++, то можно сделать отдельным подразделом (только не одного ранга с параметрическим и ad hoc, а, например, внутри "Полиморфизма подтипов").
Arachnelis 07:13, 18 июля 2013 (UTC) Arachnelis
Добавление:
Говоря откровенно, латинский идиом "ad hoc" эквивалентен русскому идиому "абы как" (не исключено, что и созвучность не случайна). Я не слышал Криса Стрэчи лично, но уверен, что уничижительный подтекст у него таки был - дескать, есть истинный полиморфизм, а есть "как сумели" (выглядит и плавает, как утка, но самом деле гамадрил). И если в английском языке латинские выражения хотя бы распространены (т.е. народ может разве что рассуждать об их толковании), то в русском придётся дать хоть какой-то перевод, и уже его сопровождать латинским оригиналом. Просто тяжело называть вещи своими именами, когда 95% программистов де-факто являются "абы как программистами", а из 5% оставшихся - 95% плачут, колются, но продолжают писать на "абы как языках". Ни одно массовое издание не рискнёт пойти на такую откровенность. Поэтому я предлагаю вариант "Ситуативный (ad hoc) полиморфизм" как буквальный, но вполне нейтральный перевод. Ещё буквальным был бы "произвольный полиморфизм", но это будет использоваться как восхваление, т.е. плюс с минусом поменяются местами. Наиболее адекватными и лингвистически удобными вариантами были бы "косметический полиморфизм" или "эмуляция полиморфизма", но, боюсь, это может вызвать слишком много споров.
Arachnelis 11:26, 19 июля 2013 (UTC) Arachnelis
=== ссылки ===
Если в качестве "ссылок" использовать материалы про реализацию полиморфизма в конкретных языках, то первыми должны идти ссылки на книги про ML — именно там рассматривается истинный полиморфизм и его отличие от перегрузки; а про полиморфизм в ООП читать про Smalltalk. Однако, я считаю, что в таких ссылках нет смысла вообще — найти книги можно в соответствующих статьях про языки. В работах про С++ и иже с ним больше заблуждений, чем истины, по ним изучать фундаментальные понятия программирования (такие как полиморфизм) вредно. Аксиоматично звучащее определение полиморфизма "один интерфейс — много реализаций" во-первых, путает полиморфизм с механизмами модульности и инкапсуляции (да, в С++ за всё это отвечают одни и те же механизмы, но это от бедности), во-вторых формирует ложное представление о том, что значит "единообразная обработка разнотипных данных" - якобы алгоритм не может работать с данными, ничего не зная об их представлении, или что это опасно. Можно ещё на Haskell сослаться, но там зашкаливающий матан, совершенно ненужный для рассмотрения понятия полиморфизма, и это опять-таки чревато сеянием заблуждений — якобы, чтобы получить истинный полиморфизм, надо расплавить себе мозг.
Arachnelis 13:59, 29 июля 2013 (UTC) Arachnelis
thread_title:  Полная корректировка 

message: Если в качестве "ссылок" использовать материалы про реализацию полиморфизма в конкретных языках, то первыми должны идти ссылки на книги про ML — именно там рассматривается истинный полиморфизм и его отличие от перегрузки; а про полиморфизм в ООП читать про Smalltalk. Однако, я считаю, что в таких ссылках нет смысла вообще — найти книги можно в соответствующих статьях про языки. В работах про С++ и иже с ним больше заблуждений, чем истины, по ним изучать фундаментальные понятия программирования (такие как полиморфизм) вредно. Аксиоматично звучащее определение полиморфизма "один интерфейс — много реализаций" во-первых, путает полиморфизм с механизмами модульности и инкапсуляции (да, в С++ за всё это отвечают одни и те же механизмы, но это от бедности), во-вторых формирует ложное представление о том, что значит "единообразная обработка разнотипных данных" - якобы алгоритм не может работать с данными, ничего не зная об их представлении, или что это опасно. Можно ещё на Haskell сослаться, но там зашкаливающий матан, совершенно ненужный для рассмотрения понятия полиморфизма, и это опять-таки чревато сеянием заблуждений — якобы, чтобы получить истинный полиморфизм, надо расплавить себе мозг.
Arachnelis 13:59, 29 июля 2013 (UTC) Arachnelis
thread_title:  ссылки 

message: К сожалению, содержимое этой статьи является полной ерундой.
Лушчее, что можно сделать, это, наверное, просто перевести английскую
статью, но у меня сейчас нет на это времени. 
Основные ошибки: ad hoc полиморфизм - это обычная перегрузка операций
Параметрический полиморфизм - это и классы типов тоже. Другим
примером параметрического полиморфизма являются шаблоны С++
OO-полиморфизм на самом деле не является прерогативой ОО-языков,
хотя и наиболее типичен для них. Он связан с отношением subtyping'a.
Может переименовать статью в Полиморфизм (программирование)? Rubynovich 13:58, 30 мая 2006 (UTC)
replies: text: Насколько мне известно, параметрический полиморфизм - когда одна реализация работает для любых типов данных, например, функция Haskell.Data.List.reverse. Пользуясь же классами типов, необходимо писать реализацию для каждого типа, относящегося к классу. Да, про шаблоны C++ я не упомянул. --beroal 00:11, 13 июня 2009 (UTC)

text: Хотел было сюда написать, но увидев "К сожалению, содержимое этой статьи является полной ерундой." первой строкой понял, что не только я считаю, что косметического ремонта недостаточно ;-) Предложение о переименовании (с перенаправлением) поддерживаю. РоманСузи 16:53, 24 октября 2007 (UTC)

text: Если кто возьмется переводить, в английском варианте есть две статьи: http://en.wikipedia.org/wiki/Type_polymorphism и http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming РоманСузи 16:57, 24 октября 2007 (UTC)
replies: text: : Поскольку в статье по-прежнему полная ерунда, повесил баннер про незавершенную статью. А то ведь будут ссылаться... Enerjazzer 04:36, 1 июня 2009 (UTC)
replies: text: :: Полагаю, этот баннер провисит ещё 5 лет, ибо никто не может написать лучше (или не хочет, если вам там приятнее думать). :) --beroal 00:04, 13 июня 2009 (UTC)
Очевидно, что не может существовать объект класса, в котором хотя бы один метод абстрактный, так как неизвестно, как он должен работать.
Развёрнутая цитата одним абзацем
Данное утверждение является неверным, так как в Delphi, например, можно создавать экземпляры абстрактных классов, но при обращении к методам данного класса, помеченным как абстрактные, генерируется исключение EAbstractError.--91.122.203.178 12:22, 14 августа 2008 (UTC)Vladimir
thread_title:  Без названия 

message: Интересные правки можно увидеть в истории:
# (отмена правки 31517032 участника 178.95.19.108 (обс) почему это?) (скасувати) [очікує на перевірку]
# (поточн. | ост.) 16:05, 31 січня 2011 178.95.19.108 (Обговорення) (21 831 байт) (коэффициент повторного использования кода чем ниже тем лучше)
Пахнет как флейм на 200 сообщений. ;) --beroal 12:59, 6 февраля 2011 (UTC)
thread_title:  коэффициент повторного использования кода 

message: Отменил сделанную участником  версию, так как полиморфизм может работать и без наследования, что делает определение слишком узким. Давайте найдем более широкий, чем посвященный C++/Java АИ и напишем по нему. Например, в книге И.Одинцова Профессиональное программирование. Системный подход говорится о том, что полиморфизм включения позволяет моделировать подтипы и наследование. Так что в абстракции данных первичен все-таки полиморфизм, а не наследование. Определение слишком узкое даже если ограничится ООП и забыть о языках функционального программирования. РоманСузи 12:59, 19 мая 2013 (UTC)
Статьи по программированию, эта и не только чрезвычайно сложны, в смысле намеренно усложнены. Все можно написать гораздо более простым языком, а нюансы и ссылочные ветвеления (описание смежных понятий, более фундаментальных категорий имеющих отношение к предмету статьи) отобразить отдельным абзацем. То есть сначала объясните суть явления, затем вдавайтесь в описание его истории и т.д.
добавлено: Нет, серьезно, зачем во втором абзаце давать 2 имени, когда важны только методы (а имена изобретателей методов отдельно, в этих статьях). Это лишняя информация. Википедия - это не свалка всевозможных известных фактов о предмете, к месту и не к месту.
С уважением.   92.240.140.99 21:26, 3 августа 2014 (UTC) Чик-Чирик
replies: text: Всё верно, я и сам планировал пере-причесать. Давно писал, зелёный по Википедии ещё был. Поправлю, обещаю. Arachnelis 20:38, 8 августа 2014 (UTC)
replies: text: : Так лучше? :) Arachnelis (обс) 19:10, 30 сентября 2014 (UTC)
thread_title:  Определение полиморфизма 

message: Посмотрел на досуге статью Луки Карделли «On Understanding Types, Data Abstraction, and Polymorphism» — там говорится еще об одном типе ad hoc полиморфизма — о приведении типов (coercion). Этого в статье не отражено. РоманСузи 20:03, 23 октября 2014 (UTC)
* Я чем больше читаю Луку Карделли, тем больше восхищаюсь им. Он виртуознейше систематизирует весь хаос, коим наводнился мир информатики за десятилетия развития. Проблема в том, что если следовать правилам Вики, и писать обо всех, никого не обидев, то придётся неслабенько так поскрипеть извилинами, ибо мы получаем прямое расхождение определений, и чтобы статьи оставались в рамках приличия, надо искать способы эти противоречия увязывать между собой. Судите сами, как получается эта его формула 2х2 вида полиморфизма. Либо тело операции единственно, либо их несколько. Если единственно, то либо операция принимает бесконечное множество типов, либо конечное. Если их несколько, то либо мы подгоняем действие под значение, либо подгоняем значение под действие.  Нетрудно видеть, что под последнее определение подпадает в том числе динамическая типизация. Если зайти с другой стороны, вспомнив 2 основных определения типа (как поведение и как множество значений), то обратно придём к тому же. При детальном рассмотрении этого концепция "политипизма" рискует превратиться в очередной академический баззворд (как сказал, если не ошибаюсь, Р.Гласс, академики обожают ко всему клеить приставку "мета-", мне как-то взорвало мозг слово "метамотивация"). Возможно, меня как-нибудь спьяну озарит хорошее построение данной статьи (а заодно и родственных), но явно не сегодня. Я например, всю голову сломал насчёт классификации Рефала с т.з. типизации, а АИ не нашёл (я давеча написал, что он бестиповый, но после появления слова "политипизм" уже не уверен в этом). Признацца, я немало сам по теории CS продвинулся, пока статьи писал и АИшечки ковырял. Пока главное, что русская Вики узнала про то, что полиморфизм - это вовсе не обязательно "много реализаций", а в идеале так и как раз наоборот. Arachnelis 21:35, 30 октября 2014 (UTC)
** Ну вот такой вариант оцените Arachnelis 17:34, 12 ноября 2014 (UTC)
*** Вроде хорошо написано. Единственное, что режет глаз: «Если функция связывает с каждым своим параметром ровно один тип»… Оборот, как мне кажется, нехороший. Функции обычно «связывают» параметры с возвращаемым значением или что-то вроде того. Может быть, система типов связывает с каждым параметром функции..? Правда, в некоторых языках, вроде используемого в coq уже сам чёрт не разберёт что и с чем они связывают, вход с выходом или выход со входом, не говоря уже о типах…  РоманСузи 18:15, 12 ноября 2014 (UTC)
**** Я это писал в соответствии с Вики-принципом "понятно даже тем, кто не в теме" - т.е. "связывает" как будто она живая и разумная. Но вообще верно, поправлю как ещё что родится. Если какие мысли будут - предлагайте. Arachnelis 11:43, 13 ноября 2014 (UTC)
***** Вспоминая наши старинные обсуждения, полагаю, что Вы правы насчёт того, нужно писать так как «правильно», а не так как принято у определённой группы (скажем, программистов на некотором языке). Но это самое «так как есть» нужно написать понятно, от простого к сложному. Только так можно вытащить читателей из скорлупы (некоторой парадигмы), иначе они останутся при мнении, что мы затаскиваем их в другую скорлупу. Нужно показать, что мир шире этой скорлупы. «Одушевление» функции и слишком плотное употребление терминов «из другой скорлупы», как я понял на себе, в этом не помогает. Уж лучше тогда просто уделить вводный абзац сведениям о связи функции с системой типов (без деталей). Но это собственно не совет, скорее отвлечённое мета-замечание. Может быть, что-то конкретное придёт. РоманСузи 11:56, 13 ноября 2014 (UTC)
thread_title:  Пропуски 

message: *Мне бы не хотелось доводить викидеятельность до стадии википидорства, ну как максимум ограничиться одной четвертью этой шкалы — стадией викимаразма. Правила требуют, чтобы информация была ПРОВЕРЯЕМОЙ, но не КОПИПАСТОЙ. Евгений Мирошниченко, у вас есть сомнения, что, например, Лука Карделли классифицировал бы этот пример как «небезопасную форму параметрического полиморфизма»? Ну так напишите письмо ему лично и попросите выступить на конференции IFIP или ACM со статьёй в один лист, состоящей из одной аннотации: «Из моих прошлых работ участники Википедии не смогли вычленить доказательство того, что тырыпыры, поэтому в данной работе я констатирую, что это таки факт, чтобы на меня таки можно было сослаться с Википедии. Благодарю за внимание. Ваш К.О.» 
*То, что Си является небезопасным языком, потому что адресная арифметика небезопасна по своей природе, а приведение типов небезопасно потенциально, исчерпывающе изложено в статье типобезопасность, с АИшечками и поэтессами. Это АДЫН. Стречи определил значение термина. Читайте страницу 37 в . Он физически не мог ограничить его рамками типобезопасности (как в Хиндли-Милнере), просто потому что он опубликовал это определение в 1967, а Система F была опубликована в 1972. Более того, Стречи вставлял примеры на BCPL, прямом предке Си, и не мог вставлять примеры на Си, так как Си оформился к 1978, а популярность уровня, чтобы на нём приводить примеры в серьёзной работе, набрал ещё позже. Таким образом, определение дано абстрактно, и поздние работы могут попадать или не_попадать под это определение. Так что функция, работающая над данными разных типов, по Стречи, называется параметрически полиморфной, вне зависимости от вашей привычки применять этот термин к коду на Си. Вероятность же найти АДЕКВАТНОЕ прямое утверждение о попадании, со ссылкой на Стречи, ассимптотически стремится к нулю (ибо никому, кроме участников Вики, ни в одно место не вперилось). Это касается вообще любого языка — хоть Тикля, хоть Руби. Поглядите, например сюда. Что, однако, ни коим образом не накладывает вики-запрет на произведение соответствующей классификации. Есть проверяемое определение, есть проверяемый пример, и очевидно, что пример попадает под определение (поскольку void* у K&R называется «generic pointer», то есть разновидность адресной арифметики, предназначенная для обобщённого программирования), и нет проверяемых оснований утверждать обратное. Это ДЫВА.
*А вообще, прямые утверждения по схеме «Мы принадлежим к такой-то категории!», если так честно говорить, положа руку на сердце, наиболее характерны для дилетантов. То есть чем меньше человек знает, тем громче усирается. Особенно хорошо это заметно по известной аксиоме, что язык для программиста всего лишь инструмент — чаще всего на этом настаивают те, кто знает один-единственный язык. Грамотные люди предпочитают абстрактные формулировки (за что быдлокодеры называют их «далёкими от реальной индустрии»). Пример — Страуструп, перевернувший представление о полиморфизме в глазах масс с ног на голову: дескать, полиморфизм надо понимать не из вызывающего контекста, а из вызываемого («много реализаций»). Не удивительно, что любого С++ника пример с Сишной qsort удивит до костей мозгов, и потому очень важно, чтобы он был здесь (это разновидность критерия значимости: если известно распространённое заблуждение, то энциклопедия должна делать на нём акцент и развеивать его). С++ники привыкли нести бред вроде «Вот, я написал полиморфную библиотеку! Что, у вас не получается использовать её с разными типами? Ну тогда надо обуть всё в шаблоны, чтобы компилятор сам построил по полиморфной реализации под каждый конкретный тип!», не понимая, что перегрузка методов при наследовании, сиречь ad-hoc-полиморфизм, это на самом деле вовсе не полиморфизм, а его эмуляция, а шаблоны — это эмуляция полиморфизма истинного. То есть шаблоны иерархий классов — это эмуляция эмуляции. Отсюда и кратно большая многословность, по сравнению с потомками ML. Но даже эта многословность не спасает, поскольку С++ уникален в наличии возможности гулять по иерархии подтипов не только вниз, но и вверх, позволяя написание  кода (эдакий анти-полиморфизм). 
*Немного оффтопика в постскриптум: Саймон Пейтон Джонс (аццки авторитетный и научно-грамотный чувак, рядом с которым Страуструпа даже заметно не будет, один из создателей языка Haskell, нашпигованного матаном по самую теорию категорий) дважды заявил, что неосилил С++, и считает это своим недостатком, потому что это лишает его права оценивать и сравнивать. Самокритичность здесь определённо для политкорректности, во избежание возможного шапкозакидательства. Но отбросим словоблудие и обратим внимание на факты: человек, который разработал язык с заоблачным порогом вхождения и своими руками реализовал его компилятор и интерфейс из него к Си, неосилил С++. Поскольку вопрос интеллекта и образования уже закрыт, остаётся лишь одна мыслимая причина: он недостаточно шизофреничен для усвоения того бреда, что составляет основу семантики С++. Надеюсь, этот оффтопик убедит вас в том, что с Си не всё так просто, и что его семантика вполне может восходить далеко не к тому же корню, что и Паскаль, и что именно отсюда все холивары и проистекают. От себя скажу так: Си — не такая же императивщина, как Бейсик или Паскаль (а следовательно, Java и C#), он одной ногой стоит в семействе Лиспа. Но Страуструп лишён понимания ФП, и увёл идеологию Си в Паскаль. Поэтому, повторюсь, такой пример является важным разоблачением. И поскольку вы не можете предъявить ОБОСНОВАННЫХ СОМНЕНИЙ в том, что он попадает под определение Стречи, то он таки попадает. Arachnelis 20:03, 21 февраля 2015 (UTC)
replies: text: * Когда перепишете текст так, чтобы его можно было читать (то есть с разбиением по абзацам), а его и прочитаю.  Евгений Мирошниченко  14:04, 22 февраля 2015 (UTC)
replies: text: :* Вообще-то, это одна мысль, а одну мысль не бьют на абзацы. Важным фактором для восприятия текста служит грамматика, а с ней у меня порядок. Но для тех, у кого большие и сложные мысли в регистре мозга не помещаются, так и быть, разбил. А на всякий случай добавлю, что на худой конец можно повесить ссылку на другую главу, где рассматривается void*. Это было бы ужасно вульгарный подход к разрешению конфликта (поскольку по сути означает рассмотрение программирования в терминах глаголов через существительные), но крайняк сойдёт. Arachnelis 19:30, 22 февраля 2015 (UTC)
* А где у Appel в A Critique of Standard ML утверждается на с. 5, что подобный подход (через void) — вообще полиморфизм? То, что такой способ нетипобезопасен — это и без АИ понятно, а я так понял, что проблема как раз признать данный пример на С как проявление полиморфизма (или «полиморфного поведения»). Некоторое время на эту тему искал, но кроме как высказываний на форумах (вроде, «наш профессор сказал, что через void — это не полиморфизм, объясните люди добрые — почему?»), ничего не нашел. РоманСузи 14:02, 6 марта 2015 (UTC)

text: * Верхний-левый угол пятой страницы, под заголовком "Polymorphic types": "in C, polymorphism can be accomplished only by using cast to avoid type-checker". Возможно, удастся найти аналогичный источник, пишущий по-конкретнее. Но пока разве этого не достаточно? Arachnelis 18:36, 7 марта 2015 (UTC)

text: *: Теперь нашёл. Кстати, на эту тему есть ещё следующее:  - без void*. Об авторитетности судить не берусь. РоманСузи 18:55, 7 марта 2015 (UTC)
thread_title:  Небезопасный параметрический полиморфизм 

message: В разделе Виды полиморфизма, Классификация, абзац 2-й, в скобках: «...в частности, его структуры — но не в смысле представления в памяти, а в смысле взаимной организации компонентов структурного типа» — попадаем в статью по кристаллографии. Когда, например, есть статьи: Структура (язык Си), Тип-произведение, Агрегирование (программирование)...—77.52.152.47 16:32, 12 июня 2015 (UTC)
* С интервики казус вышел, надо агрегирование вроде бы. Насчёт запроса источника на это предложение. Оно переведено из английской статьи, где написано следующее: «John C. Reynolds (and later Jean-Yves Girard) formally developed this notion of polymorphism as an extension to lambda calculus (called the polymorphic lambda calculus, or System F). Any parametrically polymorphic function is necessarily restricted in what it can do, working on the shape of the data instead of its value, leading to the concept of parametricity.» Я так понимаю, подтверждение надо искать именно у Рейнольдса и Жирара. Вообще же это интуитивное объяснение новичку, как это так — функция принимает вроде и любой аргумент, но при этом гарантируется типобезопасность (то есть это не динамика). Arachnelis 20:07, 25 июня 2015 (UTC)
replies: text: * Там нет слов "поведения структуры параметра в смысле взаимной организации компонентов структурного типа". --Сунприат 09:21, 26 июня 2015 (UTC)
replies: text: :* А, да это просто объяснение "на пальцах", чтобы слово "структура" не трактовали по-Сишному. Т.е. если параметр является кортежем, то несущественно как там он в памяти хранится (boxed, aligned, ordered - есть куча факторов), а существенно, что есть операции извлечения первого, второго и пр. элементов, и их число точно задано, и далее рекурсивно тип каждого. А про поведение Пирс говорит в параграфе 23.2 (с 364-365), но не так конкретно, а как уже известное понятие (а то и вообще очевидное). Arachnelis 20:18, 27 июня 2015 (UTC)

text: :* собственно, это просто не очень удачный перевод слова "shape". Можно обсудить варианты перевода. Arachnelis 07:16, 28 июня 2015 (UTC)

text: :* Такой вариант: "полиморфная функция рассматривает параметр на основе внешних свойств, а не фактической внутренней организации" Arachnelis 07:40, 28 июня 2015 (UTC)
replies: text: ::* У Cardelli: «Parametric polymorphism is obtained when a function works uniformly on a range of types: these types normally exhibit some common structure.». Так что текст мне кажется вполне подтверждён этим источником (за исключением конечно рассуждения о «не в смысле представления в памяти» — что коллега Arachnelis правильно заметил нужно лишь для разрешения неоднозначности слова структура. Поведение тоже не упомянуто, но слово «exhibit» довольно близко. Что касается варианта, меня смущает разделение «внешние свойства» против «фактической внутренней организации» (что есть «внешние свойства» с т. з. теории типов, которую мы в данной статье практикуем? Это как-то далеко уводит.). Тогда уж лучше вообще про представление памяти убрать. Как видно по отрывку из Карделли, слово shape или структура здесь не термин, так что с ним можно обойтись вольно. Имеется в виду, что у входных данных есть что-то общее. РоманСузи 15:44, 28 июня 2015 (UTC) Правда, там же: "Parametric polymorphism is so called because the uniformity of type structure is normally achieved by type parameters, but uniformity can be achieved in different ways, and this more general concept is called  universal polymorphism.". Здесь мы видим, что имеется в виду структура типа. РоманСузи 15:48, 28 июня 2015 (UTC)
replies: text: :::* Всё же последняя формулировка изящнее и для читающего впервые намного понятнее, чем имеющийся сейчас поток слов. По "внешним свойствам", например, Сишная структура и ML-записи идентичны, но адресная арифметика вскрывает существенные различия. И наоборот, кортежи в ML имеют заметное отличие внешних свойств от записей, но в действительности кортеж там - это запись с именами полей #1, #2, #3 и т.д. Таких забавностей много, но мы уже неоднократно сходились к тому, что раскрывать "спорности и относительности" лучше уже после короткого и ясного объяснения типичных случаев. Ещё немного доработал новый вариант: "полиморфная функция рассматривает параметры на основе внешних свойств, а не их собственной организации и содержания". Arachnelis 20:39, 28 июня 2015 (UTC)

text: :::* В качестве объяснения, что такое "внешние свойства", если что, можно отсылать к Python. В языке прекрасно реализована возможность эмуляции для своего класса внешних свойств списка или словаря. Arachnelis 20:46, 28 июня 2015 (UTC)
replies: text: ::::* Ну так что? Я могу заменить имеющееся выделение с запросом АИ целиком на новый вариант, или как? Arachnelis 20:15, 30 июня 2015 (UTC)

text: ::::*: Конечно, последний вариант более ясный и с источником. --Сунприат 05:09, 1 июля 2015 (UTC)
thread_title:  Кристаллическая структура? 

message: * Меня одного очень раздражают жирные стрелки-треугольнички со ссылками на нижележащий текст, обильно рассыпанные по тексту начала статьи? --Nashev 08:22, 27 февраля 2016 (UTC)
replies: text: * перенял из "хорошей" статьи Erlang, решил, что так положено. Но имхо если уж стрелки, то жирные. Arachnelis 09:17, 27 февраля 2016 (UTC)

text: * Могло быть и хуже. Мне больше нравятся текстовые ссылки, тут видимо на усмотрение основного автора. — stannic(обс)(вкл)(выкл) 03:38, 28 февраля 2016 (UTC)
replies: text: :* Не знал про разнообразие шаблонов, спасибо. Ёлочные ещё ничего, на погляжу, подумаю. Но квадратные точно фтопку, ибо их трудно визуально отличить от АИ.Arachnelis 20:14, 29 февраля 2016 (UTC)
Меня они не только видом своим раздражают, но и постоянными попытками сбить меня с линейного чтения статьи в лабиринт переходов по этим уточнениям внутри неё. У меня ж оглавление есть! Зачем они мне ещё? Статья вон вся открыта, на одной странице! Я и так знаю, что упомянутые в заголовке статьи и в преамбуле понятия так или иначе раскрываются ниже по тексту. Но ведь мало этого, эти стрелочки не только приткнуты к первому упоминанию объясняемого ниже, они ещё и встречаются не только у первого, иногда вовсе не у первого, а иногда и даже у объяснённого выше! --Nashev 00:41, 8 марта 2016 (UTC)

text: * Дело ещё в том, что подавляющее большинство (это известная статистика) пользователей интернета ПОЧТИ НИКОГДА не читают страницу целиком — пробегаются глазами по интересующему абзацу и закрывают. На Вики, в частности, это происходит, когда читатель попадает на страницу по редиректу, прыгающему на раздел статьи. В этих случаях читателю равно может потребоваться разъяснение некоторого понятия, и без навигации он может его не найти (в общем случае разъяснение может не идентифицироваться соответствующим заголовком, так как один раздел может раскрывать много связанных понятий). Это АДЫН. Бывает и более неприятно — некто решает вставить возле малоизвестного по его мнению понятия ненужное чайниковское разъяснение со спорным примером. Если навигация уже есть, то это вряд ли произойдёт. Это ДЫВА. Arachnelis 14:41, 8 марта 2016 (UTC)

text: * Кстати, а почему "сбивают с линейного чтения"? Вы что, реально проходите по каждой интервики и проверяете каждый источник, ничего не игнорируя? У меня лично уже давно глаз навострился бежать по тексту мимо обвеса. Arachnelis 14:43, 8 марта 2016 (UTC)
* Отсылки к более подробному или смежному материалу (см. далее, см. подробнее, см. также) это вполне нормальная практика и объективно "мешают" не больше, чем инфоплашки, повторяющие вводную часть, либо оглавление, повторяющее заголовки. Однако стрелки (отдельно стоЯщие), треугольники, ёлочки и вообще любая инфографика -- да ещё разные повсюду! -- это излишнее кодирование, которое кто обязан понимать?? Значок-мишень для клика -- малА. Есть же текстовые формы (выше в скобках), неужели байтов пожалели? Yury Tarasievich 05:45, 27 марта 2016 (UTC)

text: * Чукча не оформителя - чукча писателя. Давайте это в правилах обсудим? Или просто укажите, если уже есть. Я лично не вижу проблемы. Вариант (см. далее) мне уже администрация отрицала: разделы должны быть независимы, т.к. любой из них потенциально может вылиться в отдельную статью. А здесь переходы именно между разделами (только такие), ибо статья обзорная. Мне не принципиально, я стараюсь для читателя. Arachnelis 07:24, 31 марта 2016 (UTC)

text: * Кстати, поскольку это обзорная статья, то в есть и ссылки под словом, уходящие на развёрнутые статьи, и они перемешиваются с внутренними переходами. Arachnelis 07:26, 31 марта 2016 (UTC)
* Структура изложения это вообще другой вопрос. По оформлению ответил я (см. ниже), потом вижу: зря писал, никто вникать не будет -- но уж пусть остаётся :) 
Итак, посмотрите на след. фрагмент:  полиморфизм и параметрический полиморфизм.
Сколько здесь ссылок? Почему ссылки то с меткой, то без неё, и что значат метки -- дорога поворачивает вправо? А может быть, это сноска? И какая, наконец, разница читателю, ведёт этот переход внутрь или вовне?? Сетевая ссылка должна открывать нужный текст в нужном месте, и больше от неё ничего не требуется, кроме понятного единообразного визуального выражения.
Но если вариант (см. далее) ... администрация отрицала, то и говорить более не о чем. Изобретаются искусственные и небывалые правила оформления, а потом люди ревностно их блюдут и поддерживают. Yury Tarasievich 04:58, 1 апреля 2016 (UTC)

text: * Если человек хочет лишь пробежаться по обзорной статье, то он нажмёт на треугольничек позади "Параметрического полиморфизма". Если же он заходит сюда уже пятый раз с целью копнуть-таки глубже, он кликает по термину непосредственно. Возможно, в голове статьи следует под термин класть внутренний переход, ибо в разделе висит ссылка на основную статью. Конкретно над этой строчкой я ещё подумаю. В остальных случаях выбор между внутренним переходом и отправкой на подробности мне кажется расширением возможностей, а не замусориванием. Другое дело, что выглядит непривычно, поскольку далеко не все темы настолько развиты. Если их развить, то станет привычно. Arachnelis 07:47, 2 апреля 2016 (UTC)
replies: text: :* ...выглядит непривычно ...станет привычно -- вот так? Yury Tarasievich 10:11, 3 апреля 2016 (UTC)
thread_title:  Стрелки-треугольнички 

message: В русском языке нет слова "инстанс", поэтому я его заменил на экземпляр, однако правка была отменена. Чем слово экземпляр не подходит? Yanpas (обс.) 19:26, 2 января 2017 (UTC)
* С моей т. з. слово «инстанс» стало всё больше использоваться в нереферируемой «печати», но пока что не видел серьёзных источников, в которых бы термин использовался, так что не вижу большой проблемы вернуть. РоманСузи (обс.) 21:35, 2 января 2017 (UTC)
thread_title:  инстанс-экземпляр