OberonCore

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

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

С будильником у меня другой пример - когда процедуры с параметрами начинаем. "Представьте, что продавались бы будильники, которые умеют звонить в фиксированное время, и нам надо было бы хранить десяток будильников... Удобно бы было? А вот есть ручка-параметр..."


Ну да, ну да.
Потому что подавляющей широты частный случай.

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


То, что более независимо, имеет более раннюю дату рождения, например... Наконец, если мы вытащили один "болт", а обвалилось "пол-здания", значит мы вытащили его из "фундамента".
Точного определения, конечно же, не дам. Тут я не самый большой мастер.
Но мне совершенно понятно, что плевать хотели машинные языки (причем все хором), на наличие или отсутствие полимофизма в неком конкретном ЯВУ. Также как и то, что даже если бы ЯВУ и хотели наплевать аналогичным образом на машинные языки - ничего у них не выйдет.
О чем собственно и писал...
О технике.
Давно уже было, могу не все точно помнить. Но в каком-то из контроллеров, предшественников i8051, кажется был програмно недоступный стек возвратов. Аж на 3 вложения/прерывания.
Уверяю, в этом "исполнителе", никаких мечтов о полиморфизмах не было, и не могло быть - по определению. Из-за отсутствия "маленькой загогулины"

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


А мне так не кажется.
В смысле, пока мы не знаем, что в природе существуют виртуальные ф-ии - проблем нет.
В переменную записывается константа (с точностью до смещения, вносимого линкером/загрузчиком) времени компиляции.
А для виртуальных методов?
Глядя формально на запись этого присваивания, вроде бы все очевидно: там в правой части записана ф-ия, которая - вот же она, тоже имеет конкретный адрес.
А применение?
Опять же, совершенно формально, мы имеем право подставить в this любого наследника типа, записанного в сигнатуре.
Но фигня же ведь получится!!!

Ну, обычно под полиморфизмом понимают возможность протаскивать всюду, где нужно A, B, где B - расширение от A. Там уже разновидности - полиморфизм указателей, полиморфизм VAR-параметров...

А виртуализация - это позднее связывание оператора вызова процедуры с реальной процедурой, которая будет вызвана.

(Понятие времени связывания часто тоже используется как важно-общее (у Пратта-Зелковица, например). Т.е. время, когда какая-то характеристика фиксируется (например, связывание переменной с её положением в памяти, вызова с процедурой, импортируемой сущности с её реализацией и т.п.).

Ага, спасибо
Когда в Дельфи запоминают чего-то в переменную типа pocedure of object - в тот же момент и происходит связывание.
А когда в C++ запоминают метод класса, то время связывания более позднее: применение этого метода к конкретному объекту... Ума-то нету

Дык виртуальность - это подстановка нужной функции (адреса ее, конечно) в означенный указатель ВО ВРЕМЯ ВЫПОЛНЕНИЯ. Это можно сделать и вручную. Но потом, естественно, повесили на компилятор. Как и параметр this.

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

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

Посмотрим на правильность (это очень важно)
Второе правильно: для объекта вызывается нужный виртуальный метод в случае, если применяем сие к к объекту-наследнику, переопределившему этот метод. Он ведь для того его и переопределял, что бы именно со своим работать
А первое, получается - не правильно: получается способ обойти правильные действия разработчика этого конкретного типа. Возможно, даже не понимая этого.
Идеологию Zero Errors обсуждать не будем, видимо

Я иногда своих знакомых программистов тыкаю носом в этот фокус. У них челюсть на пол падает. Ходят потом.. бормочут что то.

1. В момент присваивания - это имеется ввиду при трансляции?
2. Дык потому на компилятор и повесили, что вручную - это бестиповая работа с указателями. Чревато, естественно. А на компилятор можно повесить именно то, что не всякий указатель разрешит присваивать. Я так понимаю.

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

Смысл такой: мы говорили, как бы, что процедурных типов достаточно, или нет. Мое утверждение, что - нет. И это "нет" появилось в момент добавления ООП к классическому Оберону. Т.е., при переходе к КП.
Процедуры стали "связанными", и просто так они уже процедурному типу не присваиваются. Дулю с маком, как говорится.

Дальнейшее - ну пусть называется некими фантазиями по разрешению это маленькой проблемки. Как подтверждение, что эта "проблемка" не плод моего воспаленного воображения - примеры разрешения таковой в других язЫках. В C++ - это введение типа "метод объекта", а в Дельфи - procedure of object

В пп. а) и б) я имел ввиду "плюшную" попытку разрешения вышеозначенной "проблемки".
При этом, "в момент присваивания" имеет двоякий смысл. Да, компилятор имеет информацию о том, виртуальная ф-ия, или нет. И разборки на этот предмет не будут иметь отражения в кодах (в отличие от п. б)), и сделаны будут на этапе компиляции. Ну а лазить в vmt - ну конечно в момент исполнения, хоть и при присваивании.
А при использовании - чистый адрес, никаких проблем. Хотя это и неправильно.
И поэтому C++ работает по не эффективному варианту б), осуществляя разборки "на виртуальность" (залезание в vmt, которое мы называем связыванием - это лишь одна из альтернатив этих разборок) в момент использования.
А куда ему деваться-то, если они канонизировали тип "метод объекта"

Можно пояснить? Почему фокус. Почему челюсть падает.

В PL/I и не то было, вот где надо было уши развешивать, там уже и аналоги "свойств" были и подстановка в обе стороны работала, а не какой-то там полиморфизм. Вот где можно было все. Впрочем все оттуда и свиснуто. Люди жалуются, что их ограничивают. А было настоящее наследование, есть поля с одинаковым именем - и все бери и присваивай. Есть ,к примеру, запись типа "менеджер" с полем Name и есть запись "персона" с полем Name - все присваивай в любую сторону, без всякого наследования, хотя и оно тоже было. Взял две записи имеющие методы с одним названием и сигнатурой и вперед! Хошь тот подставь хошь этот. Во были временааа! Вот еслиб люди читали фролова-олюнина, тогда им и принцип подстановки объяснять бы не пришлось. Шутка.

Потому, что это простой и красивый подход, который позволяет получить "полиморфизм" без разных там vmt и procedure of object используя только давно известный процедурный тип. Очень в духе Оберона.
Несколько раз наблюдал как люди давно и успешно программирующие начинают путаться при работе с виртуальными методами. А тут все прозрачно.
Плюс дополнительная "поведенческая гибкость" за счет рантайм-инсталлируемых методов. Такой себе "полиморфизм в квадрате".

Потому, что это простой и красивый подход ...[/quote]Спасибо.

То есть люди не понимают, как это всё ООП устроено.