Коротко. Заметки "по жизни"

По мотивам - http://programmingmindstream.blogspot.ru/2014/01/embarcadero-procedure-reference-to.html?showComment=1390421239019#c5171491385562860925

Что хочу сказать?

1. Я понял - ЗАЧЕМ Emb ARC ТАК СИЛЬНО продвигает. И дело даже не в "автоматическом уничтожении" ПОЛЬЗОВАТЕЛЬСКИХ объектов. Дело В ТОМ, что "за сценой".
2. Я ПОНЯЛ, что "лямбды" и reference to function - у Emb устроены "примерно так же как У МЕНЯ". В моей скриптовой машине. Через "интерфейсы" (объекты "словаря"), подсчёт ссылок и "захват контекста". Ничто не ново... (Это я про себя)
3. В "таком разрезе" - БЕЗ ARC - сложно обойтись.

За "подробностями" - к серии постов "GUI тестирование по-русски". Вот - начало - http://18delphi.blogspot.ru/2013/11/gui.html

Ну и последующие "одноимённые посты".

А "конца" - пока нет. Серию я ещё не закончил.

И ещё!

Читаем по ссылке - http://docwiki.embarcadero.com/RADStudio/XE5/en/Anonymous_Methods_in_Delphihttp://docwiki.embarcadero.com/RADStudio/XE5/en/Anonymous_Methods_in_Delphi

Вот цитата:
"A motivation for using method references is to have a type that can contain a bound variables, also known as closure values. Since closures close over their defining environment, including any local variables referenced at the point of definition, they have state that must be freed. Method references are managed types (they are reference counted), so they can keep track of this state and free it when necessary. If a method reference or closure could be freely assigned to a method pointer, such as an event, then it would be easy to create ill-typed programs with dangling pointers or memory leaks."

И ещё одна:
"It is possible to create a cycle in the method reference/frame link chains that causes a memory leak. For example, storing an anonymous method directly or indirectly in a variable that the anonymous method itself captures creates a cycle, causing a memory leak."

Что хочу сказать?

Я вот в "своей скриптовой машине" этих проблем - избежал.

Счастливо избежал.

"Практика - критерий истины".

У меня есть несколько сотен тестов собственно для скриптовой машины.

И они показывают, что "утечек нет".

Код например тут - https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/ScriptEngine/

или тут - https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/ScriptEngine/kwCompiledWord.pas

"техника" примерно такая:

procedure TkwCompiledWord.DoAddCodePart(aWord: TtfwWord;
  AtStartOfCode: Boolean;
  const aCtx: TtfwContext);
//#UC START# *4DB6CB1703AD_4DB6CA4F010D_var*
var
 l_Holder : TkwForwardDeclarationHolder;
//#UC END# *4DB6CB1703AD_4DB6CA4F010D_var*
begin
//#UC START# *4DB6CB1703AD_4DB6CA4F010D_impl*
 Assert(aWord <> Self);
 // - чтобы избежать циклических ссылок
 if (f_Code = nil) then
  f_Code := TtfwWordRefList.Create;
 if aWord.IsForwardDeclaration {AND
    (TkwForwardDeclaration(aWord).RealWord = Self)}
    // - проверка специально убрана, т.к. бывает вложенность
    then
 // - чтобы избежать циклических ссылок
 begin
  l_Holder := TkwForwardDeclarationHolder.Create;
  try
   l_Holder.f_Holded := aWord;
   if AtStartOfCode then
    f_Code.Insert(0, l_Holder)
   else
    f_Code.Add(l_Holder);
  finally
   FreeAndNil(l_Holder);
  end;//try..finally
 end//aWord.IsForwardDeclaration
 else
 if AtStartOfCode then
  f_Code.Insert(0, aWord)
 else
  f_Code.Add(aWord);
//#UC END# *4DB6CB1703AD_4DB6CA4F010D_impl*
end;//TkwCompiledWord.DoAddCodePart

-- ну и не надо забывать, что этот код "сильно устарел". Сейчас у меня "гораздо более продвинутые техники". Ну как всегда "на коленке"...