Полиморфизм бывает двух видов.

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

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

А ООП, это, во-первых, наличие в языке понятия идентичности объекта(Eq, ReferenceEquals, etc.), а во-вторых, типизационная идентифицирумость в рантайме(type-of, GetType(), etc.).

В этом плане вопрос не имеет смысла, т.к. что наследование, что интеграция полиморфизма, это фичи исключительно некоторых конкретных языков.

Впрочем, исторически, полиморфизм естественно появился и стал использоваться раньше какого бы то ни было ООП и наследования.

Наследование бывает разное, и полезность каждого подвида его есть своя.

И void указателем?
Всё равно же при делегировании ссылка на абстрактный класс и наследование от него.

так как ООП религия идёт через молитвы на C++|Java|Delphi? то речь про наследование в классах которые «готовятся» при компиляции и в рантайме «статичны».

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

т.е ок какие виды наследования и как полезны? при каких исходных?

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

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

Позднее связывание.

Да С++, Java и Delphi это историческое нагромождение кусков говна, зачем их приводить в примеры вопросов о теоретических основах ООП. Не видел кстати чтобы на них молились, а уж за каноны ООП в приличном обществе их тем более не считают.

Наследование бывает от интерфейса и от реализации, оба полезны.

да вообще злодеи , по что выкинули call by name

эт же позднее_связывание/полиморфизм уже в 1960!!!

Да С++, Java и Delphi это историческое нагромождение кусков говна, зачем их приводить в примеры вопросов о теоретических основах ООП.

+1

в попкультуре( а не в артхаусе лишпа и прочих монад) ооп это C++|Java - то что это големы выжившие и давшие потомство ;(

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

Строго говоря, C++ вообще не ООП.

В Java/C# энтерпрайзе наследование используется в основном от интерфейсов, полиморфизм используется повсеместно, начиная с реализации собственно функций интерфейсов и заканчивая параметрическим(для работы с БД часто, и т.п.)

Кресты — это не ООП, а недоразумение какое-то, епта. Там модульности-то нормальной нет, какое уж там ООП.

Концептуально прямое, но тормознутое, ООП возможно в ЯП со связыванием по символьному имени. Т.е. смолток, рубя, жабоскрипт и т.п.

Хотелось бы конечно больше статики: больше гарантий, больше compile-time проверок, больше скорости. На самом деле в нише не хватает адекватного (спроектированного для людей, а не для крестопоклонников, надрачивающих на 30-этажные иерархии наследований, обильно обмазанные шаблонами) статически типизированного ЯП, компилирующегося в маш.код. Есть только кресты, жава и сишарп + десяток маргинальный языков.

Кресты — это не ООП

А язык программирования. Там есть зачаточная поддержка ООП в той степени, в которой может себе позволить язык, нацеленный на нишу нативных языков с легковестным и, желательно частично отключаемым, рантаймом. «Нулевая стоимость» и все такое.

С++ вообще исторически появился из-за тормознутости Симулы67.

историческое нагромождение кусков говна

По каким критериям? Любой инструмент нужен для того, чтобы его использовали. Если инструментом не пользуются, то он говно. А если популярен, значит позволяет решать реальные задачи лучше других инструментов. Естественный отбор, ничего личного. Delphi из перечисленных вами вон тоже вымирает потихоньку, не выдерживает конкуренции.

Что существеннее курица или яйцо? И в целом, что чему предшествует концептуально?

если не анализировать то да.

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

в этом случае что существенно , а что вторично и компромисс реализации.

полиморфизьм первоначал, и мимимишный апейрон

ведь идея айперона-амера-как-там-его это и есть самый натуральный «сферический полиморфизм» в вакууме

стою 
  с iПерроном
  я 
  в лыжи 
     обутый
  толи
     эпикурейцы 
        гонят,
  толи 
     я
       --
         хипстанутый.

«сферический полиморфизм» в вакууме, без всяких там эволюций; квантовые хипсторы

сет ллойд, программируя вселенную

пролог яблоко и вселенная

«в начале был бит», — начал я. <...> «вещи возникают из информации, то есть из битов <..> это яблоко — хороший объект. яблоко часто ассоциируют с информацией. оно несет информацию о добре и зле.<..> ближе к нашей теме то, что в генетическом коде, записанном в семенах яблока, запрограммирована структура будущих яблонь. и ещё одно, не менее важное свойство: оно содержит свободную энергию — калории богатой битами энергии, благодаря которой функицлирует наше тело. <...> очевидно, это яблоко содержит информацию разных типов. но сколько оно вмещает? сколько битов в нём? что интересно, количество битов в яблоке было известно с самого начала. <..> законы квантовой механики говорят, что требуется лишь конечное число битов, чтобы определить микроскопическое состояние яблока и всех его атомов. каждый атом, а точнее, его положение и скорость содержит всего несколько битов; один спин — один бит. поэтому битов в яблоке всего навсего несколько миллионов миллиардов миллиардов нулей и единиц.» <...> «с точки зрения количества информации, которую могут хранить биты, они все равны» <..> «но все ли биты равны на самом деле?» <..>«существует ли математически строгий способ определить значимость некоторого бита?» <...> значимость бита информации зависит от того, как обрабатывается эта информация. все физические системы содержат информацию, более того, динамически развиваясь во времени они преобразовывают и обрабатывают эту информацию. естественную динамику физической системы можно воспринимать как вычисление, где бит не только содержит 0/1, но и «командует»: делай то, делай это. значимость бита зависит не только от его значения, но и от того, как с течением времени оно влияет на другие биты, будучи частью процесса постоянной обработки информации, который и составляет динамическую эволюцию вселенной

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

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

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

вот это «сериализует» в полиморфный стек и реализует связь между статической и динамической типизацией. заметь, сам тип не надо знать — достаточно знать соглашения между читателем и писателем. есть инвариант reader.type.sizeof == writer.type.sizeof.

статическая типизация:= мономорфный стек (все элементы одного типа). можно представить массивом со счётчиком верхушки.

динамическая типизация:= полиморфный стек (все типы элементов разные). но, в каждый отдельный момент времени, про верхушку стека можно сказать, что её тип — статически задан. целостность типа и неразрушение стека гарантирует соглашение между читателем и писателем.

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

к чему это я?

а вот подумалось вдруг на тему «эффективного lisp calling convention».

собственно, почему лисповый callconv будет **ВСЕГДА** менее эффективен, чем cdecl и/или STDCALL?

 cdecl callconv       | XXXlisp callconv
    ---------------------+------------------
     типы всех арг-в     |  типы всех арг-в    
      известны           | известны           
      в момент компиляции| в момент выполнения
    ---------------------+---------------------
    количество аргументов| количество аргументов
      фиксированно       |   
      (или vararg : n +  |   определяется
      в обратном порядке)|    в момент вызова
      в момент компиляции|  (destructuring-bind ...)
    ---------------------+---------------------
      1 return value     | (multiple-values ...)
    ---------------------+---------------------
      sizeof (args)      |   sizeof(args)
       фиксирован        |    неясен, произволен (destructuring-bind)
       (vararg: согл.)   |
    ---------------------+---------------------
     arg: imm_val        |  args: type tagged FIXNUM, etc
                         |   (не boxed, но нужна возня
                         |     для сохранения тайптегов)
      arg: *ptr          |
                         | ПРИЧИНА type tags:
                         |   GC перемещающий должен 
                         |   уметь отличать значения от объектов в хипе
                         |                            (хипстор-объектов)
                         
                         | ещё он должен уметь различать
                            значения, хипсторов и FFI объекты (не под GC).
                            
                          иначе moving GC (поколенческий, ephemeral)
                          может испортить хип.
    ---------------------+---------------------
      locals             | locals             | 
       выделяются в стеке|  выделяются в хипе
                         |
       alloc:            |     push argN, #heap.stack
          push argN      |
          call func      |      call N
           
       func:             |
          sub sp, NN     |         ; reuse #heap.stack
          
       free:
           add sp, NN    |    ;alloc more => облом
           ret           |    ; облом => GC find dead ends/compactifying
       ; STDCALL:ret MMM |    
                         |
                         
                
                это можно понимать как энергичное/ленивое 
                аллокацию/деаллокацию.
                
                             в этом смысле пулы (арены) и static (.bss)
                             это ленивая аллокация заранее 
                             в рантайме/при линковке.

(cont)

собственно идея в том, чтобы сделать какой-то morphic calling convention для лиспа, одним крайним случаем которого является cdecl, другим — полная динамика. чтобы этот morphic был бинарно совместим с этими callconv.

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

вот так-то.

б) : например, в ранних фортранах, или в BCPL есть массив GLOBAL. мономорфный стек == массив с счётчиком верхушки.

в) LLVM через SSA решает задачу раскраски графа. укладывается много-много элементов массива (или беск. количество регистров виртуального процессора) в несколько регистров реального процессора.

при этом на глобальном уровне всё всё ещё плохо: решается задача о укладке этого графа в полиморфный cdecl стек.

ВМЕСТО того, чтобы решать задачу о укладке графа (раскраске) в ОДИН полиморфный стек множества разнотипных регистров решать задачу о укладке в НЕСКОЛЬКО мономорфных стеков множества однотипных указателей + однотипных imm_val + битовую карту о стеках. ПРОЩЕ потому что нужно обеспечить одинаковые соглашения только в точках push/pop, при этом что-то может подсократиться ( мономорфный массив в регистры, указатель на imm_val в imm_val )

в общем, осталось решить а).

Решение. а) вместо 1 унив. call conv 1 функции вводить несколько эквивалентных для разных трамплинов в 1 функцию. б) выразить динамические соглашения (полиморфные стеки) через статические (мономорфные стеки).

про "сферический полиморфизм" в вакууме.

в общем, поинт в том, что наследование, инкапсуляцию, полиморфизм объектов можно выразить через более общий, «сферический полиморфизм»:

наследование := полиморфизм между типами классов предок-потомок по отношению is-a.
 
инкапсуляция := полиморфизм, параметризованный «по пустому».

собственно полиморфизм (объектов):= что-то, выраженное через другой полиморфизм: полиморфизм структур данных; полиморфизм кода, работающего с такими структурами; полиморфизм как в хаскелле, «типов классов». 

без всяких объектов, ага.

дискасс.

что есть из этих двух квадратноколёсных велосипедов инструмент с положительной полезностью , а что (если есть) ритуализированной случайностью ?

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

его лепят там где надо и где не надо. потому что онтология бытия такая: вначале был Object, который родил Адама, который родил Абрама, Йакова и т.д. а потом получают хрупкость базового класса и прочая.

в более другой онтологии без проблем можно создавать несколько ad hoc иерархий по разным признакам: generic, mixin, traits, в пределе, по произвольным предикатам n-го порядка, по типам, по обобщённым методам, и т.п..

поэтому нужно не наследование, а другие способы группировки, более гибкие.

Всё равно же при делегировании ссылка на абстрактный класс и наследование от него.

и позднее связывание как-то так

Позднее связывание.

«полиморфизм кода» ?

не будет ни книг, ни театра, ни кино.. ни телевидения... один только полиморфизм =))

Я обычно рассказываю об ООП так: Есть объект. На него можно смотреть (свойства) и трогать (методы/сигналы).

А все остальное реализация.

ооп это C++|Java - то что это големы выжившие и давшие потомство ;(

топик начат по причине , нужно понять и уметь обьяснить, что есть существенное

в нашем уютненьком, ООП это Эйфель, например. А вовсе не с++.

см. курсы — там было 3-4 курса по книгам Б. Мейера, ЕМНИП

во-первых, огромный талмуд «почувствуй класс с эйфель» на 1050 страниц. это почти что гради буч с OOA&OOD, только более академичнее.

во-вторых, эйфель  — пример цельной системы и метода, со своим тёплым ламповым BON вместо попсового UML. BON обладает реверсабильностью, то есть его можно отверверсить назад в код и наоборот, из кода в диаграммы ГОРАЗДО ПРОЩЕ, чем UML — потому что он не поддерживает все 10500 диаграмм UML, а предлагает свою, более внятную и краткую модель. см. сюда.

в-третьих, если это кому-то важно, в эйфеле есть множественное наследование и статическая типизация. и кодогенерация через сишечку, или ещё куда. элементарно стыкуется с С++.

вот это СУЩЕСТВЕННОЕ лучше и объяснять/понимать на примере БОЛЕЕ ДРУГИХ систем, чем C++/Java/Delphi.

например, SmallTalk (Objective C), CLOS (Dylan, Factor), Vala (GObject/COM/SOM/C++ VTable), Go (Oberon-2, Modula-2, limbo), Io (JavaScript, Self) ну и Simula-67 (C++, Java, C#)

всё это множество ООП реализаций на практике распадается в 2-3 основных принципа ООП.

и ВНЕЗАПНО, наследование-инкапсуляция-полиморфизм — это только часть из них. особенности реализации в конкретном языке, а не СУЩЕСТВЕННЫЕ свойства ООП.

потому что А. Кей например совсем не это имел в виду, а скорее, «позднее связывание».

или, какой-то такой некий «сферический полиморфизм» в вакууме, по-разному параметризованный в рантайме, в понятиях, в проектных решениях (архитектуре фреймворков на этом языке).

а что случайный эволюционый изгиб который атовизмится

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

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

оно засохнет и отвалится как хвост по ненадобности, а на его месте вырастет новый «кластер метапарадигм».

наследование используется в основном от интерфейсов

назад к истокам: что такое компонентное программирование

Если инструментом не пользуются, то он говно. А если популярен, значит позволяет решать реальные задачи лучше других инструментов.

а если инструментом пользуются ИМЕННО потому что он — говно? 95% и всё такое...

а про те которые «позволяют решать реальные задачи лучше других инструментов» говорят, что это — «десяток маргинальных недоязычков»

?

а если из перекрытой вызвать (call-next-method)? или [ :doesNotUnderstand ] ? и далее в диспетчеризацию над рантаймом.

Это будет «обратный вызов» (call back). , да, это способ позднего связывания вызовов. Но в ООП ничего дополнительно не надо для этого делать, а в модульном-структурном программировании — надо.

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

в нише не хватает адекватного (...) статически типизированного ЯП, компилирующегося в маш.код

Можно потыкать палочкой в Rust (для продакшена он пока что не очень готов)

а если инструментом пользуются ИМЕННО потому что он — говно? 95% и всё такое...

Что, прямо так и говорят «мы пользуемся, потому что он говно»? Я могу сказать про С++. Я пользуюсь им, не смотря на то, что он говно, потому что все остальное, что мне подойдет по требованиям, говно еще большее=)

а про те которые «позволяют решать реальные задачи лучше других инструментов» говорят, что это — «десяток маргинальных недоязычков»

Не, тут естественный отбор и ничего личного. Чей-либо баттхерт никого не волнует.

Или у вас есть какие-то объективные критерии говнистости?

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

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

наличие в языке понятия идентичности объекта

которое никто не юзает как надо, т.к. LSP, и штобы не парить мозг повсеместно принято, что два одинаковых по смыслу (что бы это ни значило в данном конкретном случае) объекта никогда не equals

Равносущественно. Это целостная концепция.

Часть упомянутых неэффективностей лиспа может быть убрана декларациями, часть не существует вообще. Типы аргтов могут быть известны в момент компиляции (declare ftype). Количество возвращаемых значений - тоже (вроде то же declare ftype, ЕМНИП). Разместить возвращаемые значения можно просто на стеке. sizeof args, соответственно, может быть фиксирован, если кол-во арг-тов фиксировано. Ну и ПММЛ есть разные ключи оптимизации в конкретных реализациях, к-рые, в частности, приводят к тому, что переопределение ф-ии с несовместимой сигнатурой - undefined consequences.

Насчёт type tags - видимо, да. Хотя, в теории, если функция типизирована, то нам вроде уже не нужны type tags. Сборщику мусора достаточно знать, какая функция где на стеке, хотя, в общем-то, это тоже к чему-то обязывает.

locals могут выделяться на стеке (есть декларация dynamic-extent). А биндинги локальных переменных (let), по идее, всегда должны быть на стеке, если нет против этого препятствий (замыкание, например).

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

Дальше не осилил :)

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

Главное - хвост.

Что, прямо так и говорят «мы пользуемся, потому что он говно»? Я могу сказать про С++. Я пользуюсь им, не смотря на то, что он говно, потому что все остальное, что мне подойдет по требованиям, говно еще большее=)

не, ну так прям не говорят. говорят так: «поискал кошелёк под фонарём, потому что тама ярче, а не на пустыре где потерял. не нашёл, но нашёл червончик. значит фонари рулят, а пустырь — говно».

то есть, фундаментальная ошибка атрибуции (здесь или здесь)

иными словами:

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

людишки склонны требования подгонять под свои привычки.

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

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

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

Не, тут естественный отбор и ничего личного.

скажем, так, «полуестественный». вот в книжке «producing oss software» написано, что каждое препятствие, которое адепт нового проекта встречает по пути, это барьер, и многие ниасиливают и уходят. и как эти барьеры убирать.

так вот, естественный отбор был бы если бы кто-то достаточно упорный и целеустремлённый все эти барьеры преодолевал бы.

стоит какой-то инструмент 999$? а ты заработай.

написаны мануалы по-инопланетянски? а ты разберись.

кажется непрактичным? а ты попробуй, и станет понятно.

но, вместо этого видим отбор в другую сторону — ниасиливают и уходят.

(хипсторское позёрство вместо подхода к станку инструменту — это из той же оперы, только мотивация разная)

и отбор теперь идёт по другому принципу: «как бы мне чтоб нахаляву, да ещё и не вникать, и чтоб самому ничего не делать, а слушать рекомендации лучших собаководов». ведь «Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколь-нибудь развязанное, какая у Балтазара Балтазаровича, да, пожалуй, прибавить к этому еще дородности Ивана Павловича — я бы тогда тотчас же решилась. А теперь — поди подумай!»

а вот поди и подумай.

а думать не хотят, хотят чтобы всё как у всех, наиболее массово. в итоге выбирают говно.

Или у вас есть какие-то объективные критерии говнистости?

выбирать инструмент не рационально, по-инженерному, не «от задачи», а по запрограммированным ещё зовом предков ритуалами — вот это оно самое. эдак мы далеко не придём.

говнистость, несомненно имеется. любое ворчанье «rants» как раз об этом. вопрос в том, с каким % погрешности она нам существенна. и как её преодолеть, а для этого копать надо глубже.

есть мнение, что это ошибка восприятия. а программерские заморочки — просто симптомы, которые чётче обозначают диагноз.

страшные паразиты M0 хавают мозги, и ладно бы это были какие-то ящерики с созвездия Дракона, так нет же, другая сторона своих добродетелей («lazy, impatience and hubris») — свои собственные тараканы.

копать надо глубже, и начинать с правильной картины мира. с исправления имён. потому что

Когда имена неправильны, суждения несоответственны: когда суждения несоответственны, дела не исполняются

а мы ещё из мин бянь не вышли, и не «отделили твёрдое от белого».

Хотя, в теории, если функция типизирована, то нам вроде уже не нужны type tags. Сборщику мусора достаточно знать, какая функция где на стеке, хотя, в общем-то, это тоже к чему-то обязывает.

сборщику мусора по идее вообще не нужны type tags, ему нужны только предикаты «это объект в куче или imm значение». другое дело, что по ним удобно делать диспетчеризацию и вообще проверки.

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

например: на уровне ассемблерной (или cdecl функции) стираются типы: непонятно, что значение-константа, а что указатель. GC это важно знать, но саму информацию о типах не так уж и нужно знать. type tags немного лишний. если например, эту информацию о типах не «стирать окончательно», а делать какую-то выжимку типа битовой карты из предикатов (0-константа, 1-лисп-объект в куче), то GC будет проще и быстрее работать: проще чем перебирать все параметры.

locals могут выделяться на стеке (есть декларация dynamic-extent). А биндинги локальных переменных (let), по идее, всегда должны быть на стеке, если нет против этого препятствий (замыкание, например).

вот «размещать локальные переменные в стеке» — какие opensource реализации это умеют? в коммерческих всё более-менее неплохо, а как в том же sbcl? то есть, догадаться что let можно хранить на стеке.

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

Так что из труднопреодолимых проблем я бы зачёл только type tags для сборки мусора.

есть 3 сущности: FFI указатели, родные «объекты-хипсторы», и значения. есть некоторая разница между родными и «чужими» соглашениями о вызовах. плюс ещё тонкости сборщика мусора накладываются.

есть различия в выделении памяти (аллокации на каждый чих (вызов функции)), в рантайме (лишние действия в «родном callconv», там где в том же cdecl callconv этого нет).

есть мнение, что и эти различия, и эти сущности лишние, можно дальше унифицировать и упростить.

я не говорю, что проблемы труднопреодолимые, как раз возможность встраивать в некоторых реализациях асм типа asm naked в сишечке вдохновляет. я к тому, что ИМХО упрощать надо эти «особенности», чтобы влияние в итоге на runtime/выделение памяти было меньше, более сопоставимо с той же сишечкой под valgrind.

Дальше не осилил :)

думаешь, мне легко :)) просто есть мнение, что часть можно разгрузить на LLVM с SSA, ту же разницу регистры-массивы-стеки, и что в целом, глобальном плане, как-то по-другому надо оптимизировать, например несколько мономорфных стеков вместо одного как в полиморфных cdecl, может, что-то выгорит

я тут почитываю про Corman Lisp рантайм (не так уж плохо, разве что прибито гвоздями к COM и винде) и про Factor, на некоторые мысли наводит :)))

людишки склонны требования подгонять под свои привычки.

Я помимо С++ использую еще Python, Java->Scala, Erlang. В разных проектах. Не думаю, что вы правы.

тогда ладно.

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

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

попутно оценив качество требований, и инструмента.

например, «наследование-инкапсуляция-полиморфизм» => объектная модель => другая объектная модель => ехал полиморфизм через полиморфизм, ... => стало понятнее, что тут необходимо, а что лишнее, или новая концепция/парадигма появилась, новая архитектура или фреймворки с этой архитектурой стали в 10500 раз лучше.

а не молится на эти три столпа священной ООП троицы.

ему нужны только предикаты «это объект в куче или imm значение»

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

то есть, догадаться что let можно хранить на стеке.

Лень запустить SBCL и проверить. Но ведь let создаёт «место», т.е., в первом приближении, локально действующий указатель на нечто. Вот само место (указатель) и можно хранить на стеке. А вот если в это место он записывает возврат функции cons, то этот cons уже - да, в куче.

The Ghost Not|Призрачное НЕ

Энтропия (Entropy)

Когда Трибьюс и Коста де Бюрегар обнаружили, что энтропия в термодинамике - это то же самое, что и энтропия в теории информации, они обнаружили, что энтропия в термодинамике понималась неправильно! Как доказательство этого, Трибьюс сконструировал газовую турбину, теперь уже построенную в Киото, которая потребляет на 10% меньше топлива чем прежние разработки. В период зрелости высокотехнологичной инженерной дисциплины такой огромный прогресс может показаться волшебством. Трибьюс охарактеризовал дух своего подхода «Байесовым» , а «лишняя энергия» получается заменой старого «Не определено» на новое «Возможно», что позволяет поискать возможную энергию, которую можно получить. И однажды найти ее.

посаны, серебрянная пуля где-то там, я жопой чую точно знаю =)))

вопрос ОП что важнее для «ООП» полиморфизм(т.е обобщение алгоритмов и автоопределение по типу обьекта метода) либо наследование(повторное использование и классификация «Линнея»)

кстати, вот что по этому поводу думает Алан Кей

(1)

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning — it took a while to see how to do messaging in a programming language efficiently enough to be useful).

(2)

- I wanted to get rid of data. The B5000 almost did this via its almost unbelievable HW architecture. I realized that the cell/whole-computer metaphor would get rid of data, and that «<-» would be just another message token (it took me quite a while to think this out because I really thought of all these symbols as names for functions and procedures.

(3)

- My math background made me realize that each object could have several algebras associated with it, and there could be families of these, and that these would be very very useful. The term «polymorphism» was imposed much later (I think by Peter Wegner) and it isn't quite valid, since it really comes from the nomenclature of functions, and I wanted quite a bit more than functions. I made up a term «genericity» for dealing with generic behaviors in a quasi-algebraic form.

(4)

- I didn't like the way Simula I or Simula 67 did inheritance (though I thought Nygaard and Dahl were just tremendous thinkers and designers). So I decided to leave out inheritance as a built-in feature until I understood it better.

(1): метафора: объекты — клетки организма, сообщения — сигналы между клетками

(2): метацикличность: вызов метода по селектору, то есть, сообщение «вызов метода» это метод метакласса с параметрами тип класса, сообщение

(3): термины «полиморфизм» и «обобщённость» возникли задним числом, как попытка прикрутить какую-то алгебру к «исчислению объектов»

(4): наследование оставили отдельным термином, ибо это был костыль с невнятными свойствами. Б. Мейер в книгах про Эйфель называет и наследование, и полиморфизм одним словом — «универсализация» (ср. «обобщённость»). если мы смотрим на (2) с точки зрения дочернего класса, (вызываем метод дочернего из переменной динамического типа) то это наследование : как реализация позднего связывания. если смотрим на (2) с точки зрения класса-предка, то это полиморфизм: позднее связывание позволяет вызывать метод дочернего экземпляра, т.к. динамический тип — дочерний, хотя в программе описан вызов статического типа — предка. Полиморфизм понимает, что при присваивании переменной класса предка значения объекта дочернего класса меняется динамический тип (статический остаётся предка), и использует его для (2) (а не статический тип предка).

поэтому ИМХО, «на концептуальном уровне» метафора биоклетки и вытекающий из неё полиморфизм ВАЖНЕЕ, чем особенности реализации — наследование и инкапсуляция, («костыль с невнятными свойствами»).

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

а уже хак для оптимизаций динамической диспетчеризации/связывания в рантайме типа vtable в плюсах — это «особенности реализации» конкретного языка и его рантайма (и наследование-инкапсуляция-полиморфизм — «предварительная оптимизация» этой реализации рантайма, параметризованная своим особенным понятием универсализации/обобщённости (так, что single dispatch и классификация по Линнею, а не по фолксономиям/таксономиям фасетным, например)).

кстати, сравни из «Призрачного НЕ» про Seeing like an artist: «когда художник смотрит и происходит узнавание, он оставляет в 'табло' пустое место, а когда видит отличия — помечает их пометкой. в итоге, его задача — не просто нарисовать картину, а сохранить эту исходную системность, красоту, выбрав нужные акценты (из помеченных пометкой), вписав их в общую картину, её систему. когда смотрит диадик — он фиксирует символ „есть совпадение“, а когда видит отличия — игнорирует. в итоге за деревьями не видит леса».

наследование := символ класса на табло,

полиморфизм 'сферический' (traits, mixin и прочiя его виды) := существенные отличия пометкой, каждый раз разные (а не вписывающиеся в общую 'алгебру объектов', ибо нет отдельной её, есть 'алгебра метаклассов=объектов')

выбери сам, что важнее.

в порядке метафизического бреда, навеянного 'reciprocally'

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

сравни с ООП Алана Кея: 'алгебра объектов' схлопнулась во что-то более обозримое, понятное, когда применили 'мета'парадигму над невнятной поначалу метафорой. тогда стало понятнее и с реализацией, и с оптимизацией, и со смежными местами.

возможно, метафора самой физики не очень адекватно отображает реальность: потому что мы работаем не с реальностью, а всего лишь с её моделями, и **надеемся**, что модели всё ещё отражают существенные свойства системы, не выплесканные моделями (то что моделирование адекватно). работаем с символами на табло, а не с пометками в общей картине. и надеемся, что уже выкинутый лес появится из деревьев 'сам собой', если их попилить по-другому.

а всё потому что язык не очень располагает рассуждать в таких терминах, 'алгебры метапарадигм'.

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

из этих аномалий посредством мета(физи)циклического eval вычисляются новые инварианты. которые применением мета(физи)циклического apply к аномалии, применённые в нужном месте и нужным способом, к нужной метафоре из кластера метапарадигм вычисляют следующий шаг метациклического компилятора теории-метафизики. то есть, он заодно и такой суперкомпилятор, который сам себя оптимизирует, время от времени. на каком-нибудь kanren, ага :))

естессно, метафизические шаманы могут работать с реальностью посредством 'непосредственного применения', 'прямой манипуляцией' какими-нибудь нужными комбинаторами (и шаманским диспетчеризующим вызовом комбинатора комбинаторов), даже не догадываясь о всех этих алгебрах :-))

*в порядке метафизического бреда*, ага.