Илья Ермаков писал(а):
Возможно. Я просто с непривычки не соображу, какие тут схемы применения частые покрыты будут
Вот же ж блин
Как трудно, оказывается, объяснять сверх-простые вещи....
Но мы будем ((c)Жванецкий)
Давайте на секунду забудем, что есть какой-то там ООП, и все с ним связанное.
Есть у нас возможности делать вариантность/переменность исполнения неких команд модуля???
Да конечно же - вот же он, процедурный тип!!! Вплоть до смены поведения на лету
Если мы договоримся о том, что нам совершенно понятны
схемы применения, которые будут покрыты этим типом, то дальше-то - все очень просто.
Ну вот, пришла беда, откудова не ждали - ООП называется. И сторонние разработчики стали нам предоставлять не имена процедур, а методы объектов. И не очень уточняют за их виртуальность - типа нам это должно быть не важно. Что, вообще-то, сильно похоже на правду.
Спрашивается, какое самое естественное (простое, эффективное, и т.п.) расширение этого процедурного типа, чтобы использовать те "схемы", про которые мы договорились, что нам они давно и хорошо известны.
Ответ:
procedure of object. Который не более, чем добавление еще одного адреса (this) в хранимые данные, потому-что при применении (функциональном вызове) без него не обойтись.
Что, спрашивается, может быть проще в исполнении???
Сергей Губанов писал(а):
Ну изготовьте этот тип сами если он Вам так нравится:
Вот именно так мне и не нравится.
Потому-что это технология Zero Errors
1) На самом деле я должен изготовлять не очень предсказуемое число типов, меняя ANYPTR на мои конкретные типы. Не знаю, но это не кажется рациональным для языков с RTTI - создаем некому не нужный мусор в виде дескрипторов типа. Оно нам надо?
2) В C++ так и делают с помощью шаблонов. А сделавши, говорят: "ну и фигня же получилась", и начинают делать QT - прошу принять это как экспериментальный факт.
3) Типы в полях структуры (которые обозначены как ANYPTR) должны быть тождественны - быть наследником недопустимо, А Язык это легко пропустит для метода Init
4) Может я не понял, но не увидел того самого "связывания", которое должно происходить в Init
5) Про Invoke - меня и в дельфях достали продпрограмки, только и делающие, что вызывающие другую подпрограмку. Которая опять такая же... Хотя, возможно(!!!), я не все еще освоил, и опция inline в КП есть...
Но главное-то в том, что не получается такой тип некими стандартными средствами композиции. Несмотря на всю его исполнительную простоту.
Ну не получается, хучь в ухо мочись!!!
Вот напишем тип для некой переменной procedure(R:real) of object - и эта переменная совместима как для метода "умножить" какого-то вычислителя, так и для метода "передвинуть" какого-нибудь робота.
Лишь бы сигнатуры совпадали, естественно... А тип - да по барабану, если это метод именно этого типа (а не его предка)
Тип структуры с двумя полями разных типом - это структурное прозведение
И это не от того, что мы такие умные, и так хитро придумали, а потому что "отсылателю сообщения" на самом деле по-барабану кто будет исполнять сигналы/команды.
Нооборот все: если правда жизни говорит нам, что "по-барабану", то нам именно так и надо придумывать.
((стоп себе думаю... кажется сейчас я сформулировал идеологическое различие между физиками и математиками
))
Valery Solovey писал(а):
Нету WITH после вызова? Значит есть перед ним
Неправда Ваша. Вовсе не значит. Если мы осуществляем селектирование, значит сначала кто-то это объединил в одно целое. Только это. Но совершенно не значит, что без этого объединения не обойтись.
Обойтись. И существует много случаев, когда это "обойтись" выглядит значительно проще и естественней.