arisu писал(а):
так сделано ровно по той же причине, по которой убрано DISPOSE. возвращение явного ручного управления ресурсами на пользовательском уровне — это то же самое, что и возвращение ручного управления памятью. оно не выполняет никакой практической задачи кроме радости программиста от того, что вместо записи алгоритмов ему опять дали покрутить винтики. а риторика «RAM — это одно, HDD/SDD/etc. — другое» в данном случае просто попытка ввести новые сущности туда, где они не нужны.
Это неправда, и общедоступный Close существует вовсе не потому, что разработчики хотели "порадоваться". И Adimetrius даже приводил пример, но лишь один из всего множества, если речь заходит о, тем более, всех разновидностях ресурсов.
arisu писал(а):
а если вам срочно-срочно необходимо убедиться, что всё закрыто, то для этого есть паттерн, который довольно часто применяется и в коде BBCB: вызывайте `Kernel.Collect;`. но скорее всего, в реальном софте вам это понадобится примерно никогда.
И это не правда, потому что
1. Дело не только в том, что я пишу, но и в том, что я использую, и беда в том, что многие разработчики рассуждают также, как Вы, не ведая, что творят.
2. Ресурс может долго удерживаться ненужной ссылкой, и это распространённый способ утечки ресурсов.
3. Нехватка ОЗУ никак не связана с нехваткой ППЗУ, и просто так делать обход ОЗУ ради ППЗУ - это ненужный костыль.
В целом же, закрытие нужно даже для памяти при правильном
введении параллельности в язык.
Цитата:
никто не мешает организовать и другие оптимизации
Если что-то работало медленней, а стало быстрей, то это оптимизация. Если же что-то ломается из-за нехватки памяти, потому что у некоторых разработчиков на ровном месте "нет причин", то это не оптимизация, а исправление.