Информация об изменениях

Сообщение Re[8]: Отличать от 30.10.2023 6:44

Изменено 30.10.2023 6:46 Qbit86

Re[8]: Отличать
Здравствуйте, Sinclair, Вы писали:

S>На первый взгляд да. А в каких сценариях требуется отличать null-ссылку от ссылки на разрушенный объект, который уже удалён из дерева сцены?


Например, null-ссылка может быть признаком того, что её не проинициализировали — не привязали в Редакторе перетаскиванием одного игрового объекта в поле на другом объекте. Такую ситуацию надо обрабатывать иначе, чем просто ссылку на разрушенный объект. Anyway, атомарным кирпичиком должен быть IsDisposed(), из которого можно при необходимости собрать статический метод (расширения) IsNullReferenceOrDisposed(). А не наоборот, когда у тебя цепочка if (go is null) { … } else if (go == null) { … }, причём внутри второй проверке ещё раз повторно происходит и первая (ссылочное сравнение на null).

Сопряжённым источником фрустрации для многих разработчиков Unity (они в основном не специалисты в языке) было появление в очередной версии Unity поддержки синтаксиса null propagation и null coalescing в синтаксисе C#. Раньше они не задумывались, какой механизм лежит за тем, что их ссылки как бы «обнуляются» при смерти объекта. Многим казалось, что это такая магия рантайма (а не языка — переопределение оператора). И когда они стали заменять проверки if (go != null) go.Foo() на новый модный null propagation go?.Foo(), получали изменение семантики и неожиданный NullReferenceException (вместо хотя бы ObjectDisposedException).
Re[8]: Отличать
Здравствуйте, Sinclair, Вы писали:

S>На первый взгляд да. А в каких сценариях требуется отличать null-ссылку от ссылки на разрушенный объект, который уже удалён из дерева сцены?


Например, null-ссылка может быть признаком того, что её не проинициализировали — не привязали в Редакторе перетаскиванием одного игрового объекта в поле на другом объекте. Такую ситуацию надо обрабатывать иначе, чем просто ссылку на разрушенный объект. Anyway, атомарным кирпичиком должен быть IsDisposed(), из которого можно при необходимости собрать статический метод (расширения) IsNullReferenceOrDisposed(). А не наоборот, когда у тебя цепочка if (go is null) { … } else if (go == null) { … }, причём внутри второй проверке ещё раз повторно происходит и первая (ссылочное сравнение на null).

Сопряжённым источником фрустрации для многих разработчиков Unity (они в основном не специалисты в языке) было появление в очередной версии Unity поддержки null propagation и null coalescing в синтаксисе C#. Раньше они не задумывались, какой механизм лежит за тем, что их ссылки как бы «обнуляются» при смерти объекта. Многим казалось, что это такая магия рантайма (а не языка — переопределение оператора). И когда они стали заменять проверки if (go != null) go.Foo() на новый модный null propagation go?.Foo(), получали изменение семантики и неожиданный NullReferenceException (вместо хотя бы ObjectDisposedException).