Кто шарит за kotlin

ReyMagos

Тег-бомбастер
413
7
131
Я не понимаю в чём смысл этого кода:
Kotlin:
var a: String? = null
val b = a?.length;
Если можно было не париться и сделать так:
Kotlin:
var a: String? = null;
val b = a.length; //Без знака вопроса

Логично, что в String null физически не может лежать, чего не скажешь о String?. b? по сути является безопасным вызовом, который либо выдаст b.length, либо null. Соответственно если попробовать вызвать метод без него, то будет ошибка при компиляции.

И тут самый главный вопрос. Зачем придумывать безопасный оператор вызова если можно просто всегда возвращать либо значение либо null? По сути код a.length вернёт тип Int, а a?.length вернёт Int?. Но не логичнее ли возвращать Int?, если a может быть нулевым и Int, если не может? Просто обычный метод, у которого тип результата будет зависеть от типа у которого его вызывают? Или я что-то не понимаю, так нельзя делать?
 
Последнее редактирование:
Тогда нулл может тянуться очень далеко. И ты этого в стактрейсе не найдешь.
 
А с безопасным оператором он не будет разве тянуться?
 
Если ты не будешь его использовать где попало, то нет. Тогда НПЕ покажется на месте своего появления / на результате применения оператора
 
Ну а если вот так
Kotlin:
var a: String? = null;
val b = Printer(a); // выдуманный класс для печати строки (принимает String?)
// Внутри он вызывает
printProccessor.print(a)
//Далее что-нибудь в таком же духе
//... Спустя много вызовов
val c = a?.lenght // Для чего-то понадобилась длина, а она вдруг null

Я понимаю, что Printer мог принимать String, но это уже забота программиста. Где безопасность?
 
Хотя, наверное, я не туда ушёл. Цель нуль-безопасности ведь в том, чтобы если ноль возможен, то код не скомпилируется, то бишь программист поймёт, что надо что-то менять. Сделает nullable и обработает вариант с нулём. Тогда все непредвиденные NPE будут устранены.
Но вопрос состоял в том, нужен ли дополнительный синтаксический мусор сахар, если можно от него избавится. Ведь понятно, когда может быть нуль, а когда нет. А добавлять новый оператор ради чего?

Прошу не объединять с предыдущим постом
 
То что ты кинул и не соберется. Даже если соберется то будет NPE на 4 строке.
 
Не соберётся? Тык собралось и NPE не вывело. Но я не учёл момент, что дальше с ним ничего нельзя будет сделать. Всё чертовски логично получается)

Мне очень нравится котлин и хочется, чтобы он был удобнее и понятнее, а конструкции такого вида: val l = b?.length ?: -1 немного мешают пониманию. Поэтому и хотел узнать, правда ли стоящая причина для ввода этого оператора.

Спасибо тебе)
 
Я тоже сайчас им занимаюсь. Мне только отсутствие статичных методов мешает и несовместимость лямбд. В остальном он крут)
 
Я пока только на стадии изучения. Язык реально годный, но иногда по-моему мнению синтаксис не тот, который хотелось.
Кто придумал вот это: b!!.length. Два восклицательных знака.... Зачем такое ввели? Можно же заменить обычной проверкой на нулл и бросанием NPE. Ну то есть язык нравится, но не стоит перебарщивать с сахаром - приторно будет)
 
Зачем такое ввели?
Мерзко и уродливо выглядит, а посему не хочется его использовать. Ну, собственно, авторы языка и хотели, чтобы это использовали редко, а лучше даже никогда.

Можно же заменить обычной проверкой на нулл и бросанием NPE. Н
В го так и есть, куча бойлерплейта из-за этого.
b? по сути является безопасным вызовом, который либо выдаст b.length, либо null.
b вообще не может быть нуллом - это примитив
 
Неправильно сказал. Хотел просто пример привести и к вышеизложенному коду это не относится.

Если не нравится язык, так ничего не говори! Если нравится - добро пожаловать)
 
Можно же заменить обычной проверкой на нулл и бросанием NPE
Мдя, а ничего что акцент на null-safety сделан? Чтобы наоборот избегать нуллов, не делать так: var myObject: ObjectName? = null и т.п. код. Лично я у себя два восклицательных знака вообще не использую, да и проверок на Null как таковых тоже нет.
 
Назад
Сверху