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

tchingiz_модZyK_BotaNкак это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.
Это только позволяет компилятору выполнить преобразование. Предупреждение все равно д.б. М.б. это ошибка программиста.
без преобразования.
если рассматривать нормальное наследование, а не эти идиотские примеры,
как у нас, то будет понятно, что при наследовании в подкласс добавляются
поля. Это увеличение на одну размерность кортежа.
При преобразовании ребенка в родителя - это поле надо отбросить.
Тогда об обратном преобразовании можно не мечтать, информация утеряна.

дивное единодушие во мнении с классиками

subsumption -- это правило категоризации, ребенок отнесен к категории (типу) родителя.

tchingizZyK_BotaNtchingizZyK_BotaN
тогда с потерей точности будет работать.
но тогда преобразование нужно делать явно.
с потерей точности - да.
поэтому в жизни вещественные - целые ( целые - натуральне) есть,
а по принципу Лисков их нельзя преобразовать. Они - разные типы.

авторПусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.
где здесь про перобразование типов от родительского к дочернему?
я тебе рассказывал, что оно неявно всплывает.
Оно всплывает у Мартина когда он рассматривает первый шаг -
после преобразования ребенка в родителя вызывает родительский метод.
Метод нарушает инвариант ребенка, что делает невозможным обратное преобразование в ребенка.
глава type information, lost and found в теории объектов Карделли целиком посвящена
сохранению всех атрибутов ребенка.
Послкольку они сохраняются, сохраняется возможность обратного преобразования.

Siemargltchingiz, понял про ЗПТ, типа спс за доверие.

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

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

_модZyK_BotaNкак это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.
Это только позволяет компилятору выполнить преобразование. Предупреждение все равно д.б. М.б. это ошибка программиста.
во первых, S подкласс, T надкласс.
во вторых, не ругаются.
Из подкласса в надкласс присваивать можно. Это не ошибка.
Это такое поведение компиляторов было заложено в них и постулировалось.
А потом начались сомнения и Лисков придумала принцип.

SiemarglZyK_BotaNв джаве ты не сможешь подменить объект переданный по ссылке. там явных ссылок нет.В Java все объекты - ссылки.

tchingizглава type information, lost and found в теории объектов Карделли целиком посвящена
сохранению всех атрибутов ребенка.
Послкольку они сохраняются, сохраняется возможность обратного преобразования.
В языках, где объекты только в динамической памяти - Java, .NET, D, Delphi проблем потери атрибутов нет. Преобразовывай куда хочешь.
не имеет значения где живут объекты.
Классики (Карделли и Абади в теории объектов) разрешили думать в наивной модели памяти, где переменная, объявленная классом,
- это ссылка на запись. При присвоении и передаче параметров не происходит никакого преобразования значений ( то есть записи).
происходит преобразование вида ссылки

parameter passing and assignment copy references, not the associated attribute records.

tchingiz_модZyK_BotaNкак это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.
Это только позволяет компилятору выполнить преобразование. Предупреждение все равно д.б. М.б. это ошибка программиста.
во первых, S подкласс, T надкласс.
во вторых, не ругаются.
Из подкласса в надкласс присваивать можно. Это не ошибка.
так уже для порядку


http://www.intuit.ru/department/se/oopbases/14/2.html

Предположим, что для структуры наследования на рисунке вверху объявлены следующие сущности:



Тогда допустимы следующие присваивания:


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

ZyK_BotaNegorychназови его makeRectangle() и вопросы уйдут. Если я работаю с только с квадратами, на кой хрен мне сдался прямоугольник??? и да, я понимаю, что код не скомпилится, и я буду долго ломать голову, почему, потом, наконец, залезу с исходник твоего класса, если он у меня есть, или напишу тучу unit-тестов, чтобы выяснить, как работает твой класс.

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

то есть, мое предложение о восстановлении является условием тогда и только тогда когда
выполняется инвариант типа.
Пока явного указания не нашел. Зато нашел в Бертране Мейере (автор программирования по контракту) вот такой текст



http://www.intuit.ru/department/se/oopbases/14/9.html Предположим теперь, что к объекту типа B, достижимому через сущность типа A, применяется статическое связывание. При этом из-за того, что соответствующая версия процедуры rA , как правило, не будет поддерживать необходимый инвариант (как, например, depositACCOUNT1 для объектов типа ACCOUNT2 или displayWINDOW для объектов типа BUTTON), будет получаться неверный объект (например, объект класса ACCOUNT2 с неправильным полем balance или объект класса BUTTON, неправильно показанный на экране).

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

здесь В - ребенок, А - родитель, статическое связывание - ранне связывание == вызов метода родителя