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

Сообщение Re[18]: Кровавую баню луддитам от 26.04.2017 12:15

Изменено 26.04.2017 12:18 AlexRK

Re[18]: Кровавую баню луддитам
Здравствуйте, Философ, Вы писали:

ARK>>Многопоточность (гонки) оградить borrow checker'ом.


Ф>Ничего не понял. Это кто такое, этот borrow checker? Типа Invok'а в главный поток что-то?


Это механизм времени компиляции, который препятствует написанию программ, в которых содержится более одной мутабельной ссылки на один объект. Я выше давал ссылку на полное описание.

ARK>>Абсолютно и стопроцентно НЕТ. Это как раз именно ты не понимаешь. Я говорю о полном удалении из языка целых классов ошибок, а вовсе не о замене их на другие. И, кстати, именно NULL является прекрасной иллюстрацией — он может быть совершенно безопасно удален из языка, это не просто полностью бесполезная, это вредная функциональность. Нет никаких "неправильных объектов", есть либо конкретный правильный объект, либо явно заданное значение "None".


Ф>Слово NULL меняем на слово "None"?


Нет, не просто. Я же выше написал псевдокод, демонстрирующий разницу. Что именно в нём непонятно?

Еще раз. Указатель в С может быть разыменован без проверки. Компилятор не проверяет это. Если в рантайме в точке разыменования будет null, то, в зависимости от языка, будет либо undefined behavior, либо исключение. Приведенный мной пример с union-типом полностью лишен этого недостатка, by design. Компилятор просто не скомпилирует программу, в которой стоит вызов метода у потенциально нуллабельного объекта.
Re[18]: Кровавую баню луддитам
Здравствуйте, Философ, Вы писали:

ARK>>Многопоточность (гонки) оградить borrow checker'ом.


Ф>Ничего не понял. Это кто такое, этот borrow checker? Типа Invok'а в главный поток что-то?


Это механизм времени компиляции, который препятствует написанию программ, в которых содержится более одной мутабельной ссылки на один объект. Я выше давал ссылку на полное описание.

ARK>>Абсолютно и стопроцентно НЕТ. Это как раз именно ты не понимаешь. Я говорю о полном удалении из языка целых классов ошибок, а вовсе не о замене их на другие. И, кстати, именно NULL является прекрасной иллюстрацией — он может быть совершенно безопасно удален из языка, это не просто полностью бесполезная, это вредная функциональность. Нет никаких "неправильных объектов", есть либо конкретный правильный объект, либо явно заданное значение "None".


Ф>Слово NULL меняем на слово "None"?


Нет, не просто. Я же выше написал псевдокод, демонстрирующий разницу. Что именно в нём непонятно?

Еще раз. Указатель в С может быть разыменован без проверки. Компилятор не проверяет это. Если в рантайме в точке разыменования будет null, то, в зависимости от языка, будет либо undefined behavior, либо исключение. Приведенный мной пример с union-типом полностью лишен этого недостатка, by design. Компилятор просто не скомпилирует программу, в которой стоит вызов метода у потенциально нуллабельного объекта.


Ф>Ты понимаешь, что в случае else мы будем либо исключение выбрасывать, либо делать что-то непотребное.


Конечно. Но в большинстве случаев нам это не нужно — мы просто потребуем на входе в процедуру "MyObject", а не "MyObject|None". И проблема нас уже не касается! И только где-то в самом верху у нас будет это "else", остальной код будет чистым, без возможности появления нуллов.