Является ли плохой практикой цепочка Kotlin нулевого оператора безопасности при работе с неизменяемыми переменными и свойствами? - PullRequest
Новая
       28

Является ли плохой практикой цепочка Kotlin нулевого оператора безопасности при работе с неизменяемыми переменными и свойствами?

1 голос
/ 04 мая 2020

Возьмите гипотетический псевдокод, приведенный ниже, в качестве примера: 

val a: Any? = ...
a?.takeIf { ... }
    ?.apply { ... }
    ?.let { ... }

Я недавно прочитал статью, в которой предлагалось, что использование такого типа нулевого оператора безопасности создает избыточные проверки нуля при компиляции в Java Машинный код. Здесь - в соответствии с этой статьей - может показаться, что при компиляции, когда a != null оценивается как true, он по существу проверяет, если a != null три раза для одной и той же переменной. Это может произойти с тех пор, когда вы имеете дело со свойством var, которое может изменять значения между проверками. Но в ситуациях с неизменяемыми свойствами val это создает избыточные проверки. Если приведенный выше пример выполняется для каждого элемента в перечисляемой структуре данных, это будет линейно масштабировать избыточные проверки, делая конечный результат в 3 раза более сложным в вычислительном отношении, чем это необходимо.

Синтаксически это делает много смысл использовать Kotlin таким образом. Но если он производит бесполезные / избыточные проверки, подобные этой, кажется, что лучше этого избежать, явно проверив значение переменной null с помощью оператора if.

Уместно ли объединять в цепочку использования нулевого оператора безопасности, особенно в сочетании с лямбдами, которые бы проверяли одну и ту же неизменяемую переменную несколько раз? Или, другими словами, действительно ли это приведет к чрезмерным / избыточным проверкам нуля в скомпилированном java машинном коде?

...