Количество ссылок на объект

[gloomyBrain]

Хм.. я вообще про то, что CASALib в принципе не может удалять все ссылки, до тех пор пока объект не IDestroyable.

[Zebestov]

если просто null-нуть ссылки на оба экземпляра (в любом порядке) — все исчезает по GC.

[i.o.]

Хм.. я вообще про то, что CASALib в принципе не может удалять все ссылки, до тех пор пока объект не IDestroyable.

Не понимаю чего так расхваливать CASALib. От того, что мы создали объект и имлементили ему касалибовский IDestroyable, ссылки чудеснейшим образом не станут удаляться сами по себе. Точно также, ручками, нужно будет прописать в destroy методе, что мы собственно зануляем и уничтожаем.
С тем же успехом можно свой IDestroyable написать и смысл не изменится.
Буди что со экранными объектами автоматизировано их рекурсивное удаление из дисплейлиста и вызов в каждом destroy - так тоже, писать метод 5 минут. Но все остальные переменные класса все равно ручками занулять в destroy нужно.

[bebop]

Сообщение от i.o.

Не понимаю чего так расхваливать CASALib. От того, что мы создали объект и имлементили ему касалибовский IDestroyable, ссылки чудеснейшим образом не станут удаляться сами по себе. Точно также, ручками, нужно будет прописать в destroy методе, что мы собственно зануляем и уничтожаем.
С тем же успехом можно свой IDestroyable написать и смысл не изменится.
Буди что со экранными объектами автоматизировано их рекурсивное удаление из дисплейлиста и вызов в каждом destroy - так тоже, писать метод 5 минут. Но все остальные переменные класса все равно ручками занулять в destroy нужно.

Destroyable отписывается от событий DestroyableEventDispatcher после вызова destroy. Или это тоже 5 минут писать?

[Psycho Tiger]

Вообще то да)

[bebop]

ну значит никаких проблем

[gloomyBrain]

Не понимаю чего так расхваливать CASALib

Я и не хотел этого. Более того, прекрасно обхожусь без нее и ей подобных библиотек, ибо при нормальном подходе польза от нее сомнительная

Но все остальные переменные класса все равно ручками занулять в destroy нужно

Не обязательно. Как уже заметил Zebestov - если нет ссылки на сам объект, то нет и ссылок на его свойства.

[Psycho Tiger]

Глум, я написал ведь. Если 2 объекта очень "сцепленны" может быть ситуация, в которой GC будет думать что ссылки на них остались.
Хотя, эту статью где про это рассказывалось читал очень давно. Может, сейчас дела обстоят лучше.

[Zebestov]

Psycho Tiger, только что проверил.

Немного измененный пример gloomyBrain:

package {
 
	/**
	 * ...
	 * @author gloomyBrain
	 * @mail CartoonRaccoon@gmail.com
	 */
 
	public class LinkHolder {
 
		private var _link:Object;
 
		public function LinkHolder() {
 
 
		}
 
		public function set link(link:Object):void
		{
			this._link = link;
		}
 
		public function get link():Object {
			return this._link;
		}
 
	}
 
}

при "перекрестном использовании":

package 
{
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class Main extends Sprite 
	{
		private var a:LinkHolder;
		private var b:LinkHolder;
 
		public function Main():void 
		{
			if (stage) init();
			else addEventListener(Event.ADDED_TO_STAGE, init);
		}
 
		private function init(e:Event = null):void 
		{
			removeEventListener(Event.ADDED_TO_STAGE, init);
			// entry point
 
			this.a = new LinkHolder();
			this.b = new LinkHolder();
 
			this.a.link = this.b;
			this.b.link = this.a;
 
			stage.addEventListener(MouseEvent.CLICK, this.onClickHandler);
		}
 
		private function onClickHandler(e:MouseEvent):void
		{
			this.a = null;
			this.b = null;
			// запускаем GC и наблюдаем исчезновение
			// обоих экземпляров LinkHolder
		}
 
	}
 
}

не вызывает "зависания" экземпляров — GC разобрался =)

[Psycho Tiger]

Нет, суть не в этом. Я очень упрощенно сказал, на самом деле ссылок должно быть очень много друг-на друга и желательно больше, чем в 2 объектах. То есть 5 связанных классов, каждый с которым связан, причем больше, чем одной ссылкой.

Короче, ужасный код должен быть)