Тут Вит запостил на мой взгляд очень интересные темы. Решил я с RTTI тоже по-экспериментировать и вот что у меня получилось (хотя для кого-то это все равно, что Америку открыть, для меня - нет). Прошу пояснить как же так получается?
Вот код:

procedure TForm1.Button2Click(Sender: TObject);
begin
TEdit(Button1).Color:=clred;
edit1.Color:=TEdit(Button1).Color;
end;

Получается, что Button1 хранит значение св-ва Color (причем вместо TEdit во второй строке можно TLabel написать), а у него такого св-ва нету... Мало того, если, например, добавить еще одну кнопку (Button3) и написать Button3:=Button1 то происходит "передача" св-ва колор.
Если в кратце не получиться, то хоть ссылку...

Тут нет никакого РТТИ.

TEdit(Button) - это аналого reinterpret_cast из С++,
если ты понимаешь, о чём я. То есть компилятор никак не контролирует твои действия. То есть ты просто перезапишеь какие-то данные Button,
грубо говоря, испортишь объект.

RTTI имело бы место, если бы ты написал
(Button as TEdit).Color := ...;

И тогда бы ты получил EInvalidCast, что вполне справедливо.

TEdit и TButton - наследники TControl, в котором вводится свойство Color (на этом этапе иерархии оно скрыто). Некоторые наследники делают его видимым, но имеется и хранится оно у всех детей по одному адресу (новые поля у наследников добавляются в конец)

Цитата(Guest @ 30.9.2002, 13:50)

Тут нет никакого РТТИ. грубо говоря, испортишь объект.

Ну нет и нет. Просто в тех книгах что у меня есть в разделе про RTTI такие операции как TEdit(TSomeObject) описывались как аналог AS. Или может я читал не внимательно   Что значит "испортишь объект"? А если, как написано выше Button3:=Button1, я и его "испорчу"?

"Испортишь объект" - значит, перезапишешь его данные левыми значениями.
Например, в поле, хранящее ссылку на другой объект  запишешь цвет.
Угадай с трёх раз, что у тебя получится при обращении по этой ссылке? -
правильно, AV.

Т.о. поведение испорченного объекта непредсказуемо.

При Button3:=Button1 вообще никакого копирования не происходит.
Просто две ссылки Button3 и Button1 будут указывать на один и тот же
объект.

А про "аналог" - действительно, эти операции в некотором роде аналогичны.
Обе они производят приведение типов.
Просто в одном случае (as) - с проверкой корректности приведения во время исполнения (с использованием RTTI), а в другом - без.

Если ты, например, уже проверил, то можешь не использовать as (оно дольше работает):

if Obj is TClass1 then
begin
 TClass1(Obj).Чего-то там;
 //Здесь можно не использовать (Obj as TClass1), т.к. проверка уже проведена,
 // и ты точно знаешь, что приведение возможно
end;

Что-то обычно я не встречал запорченных объектов ни после TClass1(class2) ни после class2 as TClass1. Обычно преобразования проходят если свойство происходит от общего предка (даже если его проявление "заблокировано" в потомках), и ничего страшного не происходит - например можно поменять Caption у объекта TEdit - и оно поменяется! - если сделать Docking TEdit то заголовок "докированной" формы будет именно тот на который поменян, а вот если типы не совместимы то хоть  TClass1(class2), хоть class2 as TClass1 генерят ошибку либо "Invalid typecast" либо "Abstract Error", но не AV

Цитата

Обычно преобразования проходят если свойство происходит от общего предка (даже если его проявление "заблокировано" в потомках)

Это частный случай. В этом случае действительно всё сработает правильно.
Случай, который привёл я, с AV, - тоже частный.
Может получиться что угодно. (В случае TClass1(Obj2))

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

Код

TEdit и TButton - наследники TControl, в котором вводится свойство Color (на этом этапе иерархии оно скрыто). Некоторые наследники делают его видимым, но имеется и хранится оно у всех детей по одному адресу (новые поля у наследников добавляются в конец)

Само по себе насколько я помню, Color - это propeprty, так что на самом деле будет вызван какой-нибудь метод типа TEdit.SetColor, где self будет указывать на тот TButton. Сам по себе этот метод не меняет кажись никаких полей, а вызывает API на соответсвующем handle(которое храниться уже как поле в TWinControl?). Так что тут никаких данных опять таки перезаписанно не будет. Вот еще одно достоинство использования property! Шутка.

Цитата

Мало того, если, например, добавить еще одну кнопку (Button3) и написать Button3:=Button1 то происходит "передача" св-ва колор

В этом случае скажем еще раз: в Delphi переменная типа класса является указателем! Адрес ты этому указателю и задаешь, вызывая класс функцию Create, которая динамически создает объект, и возвращает указатель на этот объект.

Спасибо, довольно исчерпывающе. Особенно про частные случаи. А то сразу - испортишь! в холодильнике хранить надо! Еще раз всем спасибо.