Этот объект переживет сборку мусора в F #? - PullRequest
Новая
       11

Этот объект переживет сборку мусора в F #?

0 голосов
/ 17 января 2020

У меня есть объект F #, подобный этому: 

type myObject() = 
    ...
    do
        // calling a 3rd party lib that will do
        // callbacks into this object's methods

, и в своей основной инициализации я делаю это: 

let _ = myObject()

и go вкл. С остальной частью code.

Итак, этот объект настраивает обратные вызовы из сторонней библиотеки; обратные вызовы собираются приземлиться в этом объекте, но на сам объект нигде не будут ссылаться.

Вопрос 1: переживет ли этот объект сборку мусора

Вопрос 2: если нет, как его сделать постоянный

1 Ответ

2 голосов
/ 17 января 2020

Я думаю, что вопрос о том, останется ли ссылка на объект, назначенный заполнителю _, останется ссылкой из того места, где он объявлен, не является важным вопросом здесь. Важный вопрос заключается в том, будет ли внешняя библиотека сохранять ссылку на объект. Для большинства обычных библиотек, которые я могу придумать, это будет так. Например, рассмотрим что-то вроде этого: 

let register f = 
  let tmr = new System.Timers.Timer(1000.)
  tmr.Elapsed.Add f
  tmr.Start()

type MyObject() as this = 
  do register this.Foo
  member x.Foo(_) = printfn "hi"

let _ = MyObject()

Здесь реализация таймеров. NET должна сохранять ссылку на все созданные вами таймеры (чтобы они могли их запускать) и Таймер, который мы создаем, хранит ссылку на экземпляр MyObject. Независимо от того, создает ли _ ссылку или нет, на объект будет ссылаться обратный вызов.

Я могу придумать лишь несколько способов, которыми вы могли бы зарегистрировать обратный вызов, не сохраняя ссылку на объект - и это, скорее всего, будет с использованием собственного взаимодействия и небезопасного кода. Если это то, что вы делаете, то лучше создать глобальное ResizeArray где-нибудь в поле stati c и сохранить там ссылку на ваш объект. Во всех других обычных случаях вам не нужно беспокоиться об этом.

...