В Golang нет слабых ссылок, но есть финализаторы. Я раньше не знал, что можно выразить первое через второе.
А именно:
* создаём объект
* для него делаем обёртку - "капсулу жизни", ну, или можно назвать яйцом, в котором игла, в которой кощеева смерть.
Это - запись из одного поля, а это поле - наш объект (укль на него)
* у капсулы жизни делаем ещё две обёртки. Одну называем "слабой ссылкой", другую - "сильной ссылкой". Обе обёртки - это записи из одного поля,
а полем является укль на ящик.
* в качестве сильной ссылки передаём "сильную ссылку"
* в качестве слабой ссылки передаём "слабую ссылку"
* любое обращение к методам нашего объекта будет включать два разыменования (за удовольствие надо платить)
* ставим "сильной ссылке" финализатор, который обнуляет укль в капсуле жизни.
Как я понял, в Go это можно сделать через включение структур, при этом двойное разыменование укля будет незаметным. Единственное, не
возможен ли в Go побег указателя на реальный объект через присваивание? Да и в Обероне тот же самый вопрос. Однако, такие случаи мы свалим на программиста, как это принято делать в Си :)
Реализация слабых ссылок через финализаторы
-
Лис [Вежливый]
- Сообщения: 563
- Зарегистрирован: 08.10.18 13:32
Re: Реализация слабых ссылок через финализаторы
1) «Слабые ссылки играют важную роль в обработке событий,
где подписчик не должен оставаться "живым" только из-за того, что он подписан на событие.
Например, событие таймера, которое обновляет некоторые данные.
Любое количество объектов может подписаться на таймер, чтобы получать уведомления,
факт подписки на таймер, не должен сохранять их в "живом" состоянии.
Для того, чтобы это стало возможно, таймер (его список рассылки) должен запоминать подписчиков при помощи слабых ссылок»
С моделированием времени в вычислительных системах и мозгах вообще всё непросто:
https://www.youtube.com/watch?v=XD5w6r-tqXE
«When a root points to an object, the object cannot be collected because the application's code can reach the object. When a root points to an object, it's called a strong reference to the object. However, the garbage collector also supports weak references. Weak references allow the garbage collector to collect the object, but they also allow the application to access the object. How can this be? It all comes down to timing.
If only weak references to an object exist and the garbage collector runs, the object is collected and when the application later attempts to access the object, the access will fail. On the other hand, to access a weakly referenced object, the application must obtain a strong reference to the object. If the application obtains this strong reference before the garbage collector collects the object, then the garbage collector can't collect the object because a strong reference to the object exists.»
2) создание/реализация/имплементация разных кешей. Например когда пользователь ходит по дереву файловой системы, неизвестно куда он пойдёт, а памяти может и нехватать. Тогда храним дерево слабыми ссылками, если оно местами случайно рассеялось - перестраиваем с диска заново.
В википедии отмечается ( https://en.wikipedia.org/wiki/Weak_reference ) , что случай кеширования - особенный, и это может привести к созданию третьей разновидности ссылок.
3) для обеспечения работоспособности кода, написанного при помощи сборщиков мусора, основанных на подсчёте количества ссылок (а не трассирующих сборщиков мусора).
где подписчик не должен оставаться "живым" только из-за того, что он подписан на событие.
Например, событие таймера, которое обновляет некоторые данные.
Любое количество объектов может подписаться на таймер, чтобы получать уведомления,
факт подписки на таймер, не должен сохранять их в "живом" состоянии.
Для того, чтобы это стало возможно, таймер (его список рассылки) должен запоминать подписчиков при помощи слабых ссылок»
С моделированием времени в вычислительных системах и мозгах вообще всё непросто:
https://www.youtube.com/watch?v=XD5w6r-tqXE
«When a root points to an object, the object cannot be collected because the application's code can reach the object. When a root points to an object, it's called a strong reference to the object. However, the garbage collector also supports weak references. Weak references allow the garbage collector to collect the object, but they also allow the application to access the object. How can this be? It all comes down to timing.
If only weak references to an object exist and the garbage collector runs, the object is collected and when the application later attempts to access the object, the access will fail. On the other hand, to access a weakly referenced object, the application must obtain a strong reference to the object. If the application obtains this strong reference before the garbage collector collects the object, then the garbage collector can't collect the object because a strong reference to the object exists.»
2) создание/реализация/имплементация разных кешей. Например когда пользователь ходит по дереву файловой системы, неизвестно куда он пойдёт, а памяти может и нехватать. Тогда храним дерево слабыми ссылками, если оно местами случайно рассеялось - перестраиваем с диска заново.
В википедии отмечается ( https://en.wikipedia.org/wiki/Weak_reference ) , что случай кеширования - особенный, и это может привести к созданию третьей разновидности ссылок.
3) для обеспечения работоспособности кода, написанного при помощи сборщиков мусора, основанных на подсчёте количества ссылок (а не трассирующих сборщиков мусора).