Я ранее использовал в основном управляемые языки
И потом говорят, что образование в области программирования никому не нужно.
1.1. Правильно ли я понимаю, что метод Free, не смотря на обыденную декларацию, является не простым, а "магическим"
Неправильно.
И написать свой такой же метод с другим именем не получится?
Без проблем.
Зачем проверка Self на nil?
Это удобно. Без этого потребовалось бы писать:
1.
2.
3.
4.
5.
finally
if A <> nil then A.Destroy;
if B <> nil then B.Destroy;
if C <> nil then C.Destroy;
end;
Метод Free придумали ровно для того, чтобы не плодить такого убожества.
Разве Self - это не "магическая" константа/переменная, которая всегда указывает на текущий экземпляр?
Вы вводите несуществующее волшебное понятие "текущий экземпляр", и оно вводит Вас в заблуждение. Self - это скрытый параметр подпрограммы, являющейся методом класса. Рассмотрите две условных подпрограммы:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
{ Первая }
procedure Foo(ASelf: TBar; ANewValue: integer);
begin
ASelf.Value := ANewValue;
end;
{ Вторая }
procedure TBar.Foo(ANewValue: integer);
begin
Value := ANewValue;
end;
и поймите, что вторая - это просто синтаксический сахар, более удобная запись первой. В процессе развития языков программирования, когда стало много подпрограмм первого типа - для них придумали синтаксис, позволяющий записать их так, как записана вторая.
Так же, как может быть равен nil любой другой объектный параметр подпрограммы.
1.3. Если Self таки бывает равна nil, то, простите, чему или кому принадлежит код, который в этот момент выполняется?
С чего Вы взяли, что код кому-то принадлежит? Может, этот кто-то ещё может выполняемый код купить, продать или там подарить? Код как Матроскин, свой собственный.
2. Типичная ситуация, когда экземпляр класса генерирует событие, запускается обработчик, который в цепочке вызовов на определенном этапе уничтожает тот экземпляр.
Она не типичная, а довольно дурацкая.
И беглая проверка показала, что этот код даже работает. Но чует мое сердце, что работает он только до той поры, пока в промежутке после вызова Button1.Free и до полного выхода из внутренностей TButton, кто-то шустро не займет освободившуюся от Button1 память.
Вопрос не в том, займёт или нет. Вопрос в том, что после вызова деструктора не должно происходить обращений к полям и виртуальным методам этого объекта. Фактически после этого вызова Self становится невалидным указателем и не должен использоваться. Но проконтролировать это сложно, и можно быть уверенным, что когда-нибудь здесь начнутся проблемы.
2.3. Если встроенной защиты нет, то как в среде делфистов принято выходить из таких ситуаций?
Во времена Delphi 1 придумали метод TForm.Release специально для решения этой проблемы. Минус подхода в том, что он правильно работает только если в коде не употребляется Application.ProcessMessages. Как принято выходить.... ну, в первую очередь - обычно в них просто незачем входить. Опишите ситуацию, где Вы хотите такое делать - и 99.9% окажется, что нужно присвоить компоненту адекватного Owner-а и ничего руками не дёргать.
Тем не менее, если очень хочется - такое можно вполне безопасно делать, если Free вызывается последним в обработчике события.
