mayton
Вы ратуете за немедленное удаление ссылки обьектом родителем.
Совершенно не обязательно, кстати. Правильнее сказать "за оповещение родителем".

maytonНо при этом вы совершенно не рассматриваете вопросы ссылочной целостости.
Их незачем особо рассматривать - для них есть давние и проверенные решения.

Есть две симметричные проблемы - "ссылочной целостности" и "зомби, оставшегося висеть на ссылке". При работе в Java у меня регулярно болит голова на тему "все ли я сделал, чтобы эта хрень могла спокойно помереть". Лично я очень не люблю стиль работы, когда об одной и той же детали надо помнить в нескольких местах. С моей точки зрения идеальный класс сам, внутренними механизмами должен решать свои технические задачи. Инициализация, деинициализация и прочее - это техника.

Как удобный пример - давайте рассмотрим некое глобальное оповещение, на которое должнен отреагировать наш объект. Как это делается в JDK: в нашем классе делаем listener соответствующего типа, регистрируем его в объекте-оповещателе. В нашем классе делаем метод close(), выполняющий removeListener(). В пользователе нашего класса делаем метод close(), вызывающий наш close(). В пользователе пользователя нашего класса делаем метод close().... Если мы где-то ошибемся, цепочка оборвется. Если нам повезет, в результате образуется оторванная группа, которую GC таки прихлопнет; если нет - в результате куча объектов останется висеть до конца. Как правило, нам не везет (поскольку "глобальные" объекты имеют обыкновение быть сильно связанными). Если нам совсем не повезет, такой вот недоприхлопнутый объект вылезет в неожиданном месте (у меня так однажды была замечательная ошибка - я выполнял команду "aw detach", шел notification на refresh, и недоубитый объект выполнял команду, приводившую к "aw attach").

Как это делается в моей дельфовой программе - постараюсь описать терминами явы. Выполняется


И собственно все. Теперь, если myObject уничтожается, он (автоматически, на уровне стандартного кода, спрятанного далеко в предках AnyStandartObject) дергает созданный экземпляр Notification; последний выполняет notificationSender.removeListener (this). Если уничтожается notificationSender, он также дергает notification, который внутри себя делает mNotificationSender = null. Наконец, если я захочу "до срока" прихлопнуть созданный notification, тот выполнит те же самые разрегистрации.

Ключевыми здесь мне представляются два фактора: во-первых, мне не нужно ни в одном месте программы за пределами этого new думать о созданном notification-е, во вторых, если я явно убиваю какой-либо объект, я могу быть практически уверен в том, что тот "мертв и уже никогда не оживет". Для Java мне пока что не удалось найти или сделать столь же удобную технологию.

maytonВы предлагает логику сбора мусора вынести в деструкторы каждого класса
Ровно наоборот. То, о чем говорил Sarin, как раз не требует никакой специальной поддержки в деструкторах пользовательских классов; все реализовано на уровне деструкторов базовых классов.

maytonи свалить проблемы на разработчика. А это не есть хорошо.
Хм. Дозвольте утверждение. Я работал в должностях типа "ведущий разработчик - руководитель проекта" в достаточно больших проектах на дельфе, на плюсах и на яве. Так вот, из проблем, так или иначе доходивших до меня (то есть возникавших у меня либо тех, с которыми просили помощи мои программисты) именно на java много выше процент "технических", не имеющих отношения к функциональности.

Разумеется, нельзя точно сравнить степень владения разными разработчиками разными инструментами. Но - либо именно в случае Java мне попались на редкость тупые разработчики, включая меня самого, либо таки проблем больше, чем выгоды. Другой вопрос - какая часть этих проблем обусловлена именно GC, а какая - другими, может быть неудачными аспектами инструмента; тут уже не готов уверенно утверждать.

maytonВ некоторых языках и технологиях (LISP-machine) которые возникли задолго до появления .Net и Java без GC вообще нельзя обойтись. И это не бантик, а концепция.
GC, безусловно, концепция.

Простите, а насчет необходимости gc в Лиспе - насколько авторитетное утверждение? Я нисколько не оспариваю уместность там GC, но по моей прикидке для Лисп-машины таки возможна реализация без GC, пусть несколько извратная.