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

Сообщение Re[77]: Когда это наконец станет defined behavior? от 16.05.2023 16:55

Изменено 16.05.2023 16:56 ·

Re[77]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:

s> ·>Т.е. "мамой клянус". Я знаю. Возражение-то в чём?

s> В том, что в C++ есть возможность написать const для объекта. В Java нет.
В java другие подходы для реализации ровно того же.

s> ·>Ок.

s> Ок что? Где цитата, которая подтверждает, что я что-то утверждал или "что сел в лужу с ссылками и указателями"?


s> ·>То есть нет никаких гарантий, всё мамой клянус.

s> Дяденька, вы реально настолько поехавший?
Где уж мне до вас, дяденька.

Thread
launch_thread(Iterable<String> v, int iterations) {
    // Здесь компилятор запрещает модифицировать v.
    return new Thread(()-> {
        // Здесь компилятор запрещает модифицировать v.
        var l = v.stream()
            .limit(iterations)
            .mapToInt(String::length)
            .sum();
        System.out.println("iterations: " + iterations + ", l=" + l);
    });
}

Попробуйте этом коде просто так модифицировать v.

Да, там есть нюанс с Iterator, но это, к сожалению, исторический казус и плохое легаси. collections api в jdk не идеальный. Но это проблема конкретно JDK, а не ЯП.

s> ·>зато в c++ молитва const позволяет писать правильный код.

s> Да.
Ок. Если тебе помогает, можешь молиться в сердце своём. А const в код впендюривать не обязательно.

s> ·>У тебя опять память подводит. Есть final, record и даже sealed интерфейсы.

s> Ну и как с помощью этого всего сделать из HashMap неизменяемый HashMap? Ну вот был HashMap, требуется сделать так, чтобы его модифицировать нельзя было.
Если в типе изначально не предусмотрена константность (не предусмотрены методы с const), то ты нихрена не сделаешь. В HashMap не предусмотрена константность.
Однако, объект HashMap можно сделать неизменяемым, например, с помощью Collections.unmodifiableMap.

s> ·>Как и const. Всё верно.

Для клинических идиотов повторю еще раз:
void mutate(ArrayList<String> v);

Iterable<String> immutable_value = new ArrayList<>(...);
mutate(immutable_value);

Попробуйте заставить компилятор принять у вас такой код.

s> ·>И что? У тебя проблемы с логикой. Достаточно одного опровергающего примера и похрен на миллион подтверждающих.

s> Хде, хде, блин, этот опровергающий пример? Пока ни одного не было. Были примеры с наличием const-ссылок, но отсутствием const-объектов.
Именно. И это никак компилятором не проверяется. Всё на честном слове — не забыл (не смог, т.к. его надо было собрать из кусочков, например) поставить const на объекте — сработает. Не смог — не сработает. И компилятор будет молчать.

s> ·>Ровно это же можно сделать с иммутабельными типами.

s> Еще раз для клинических идиотов: дополнительные сущности, которые программист должен делать вручную (хоть и посредством IDE) без какого-либо контроля со стороны компилятора.
Описывать const-методы программист тоже должен делать вручную. Т.е. решить какие вещи в данном типе могут, а какие не могут быть const.

s> ·>В твоём примере показано

s> Да, было показано:
s>
s> int main() {
s>     const vector_of_string immutable_data{ "Hello"s, "World"s }; // Все, гарантии появились.
s>

Вопрос был: "как же константность объекта там _гарантированно_ появится?" Откуда в данной строчке будет гарантированно стоять модификатор const?
Re[77]: Когда это наконец станет defined behavior?
Здравствуйте, so5team, Вы писали:

s> ·>Т.е. "мамой клянус". Я знаю. Возражение-то в чём?

s> В том, что в C++ есть возможность написать const для объекта. В Java нет.
В java другие подходы для реализации ровно того же.

s> ·>Ок.

s> Ок что? Где цитата, которая подтверждает, что я что-то утверждал или "что сел в лужу с ссылками и указателями"?


s> ·>То есть нет никаких гарантий, всё мамой клянус.

s> Дяденька, вы реально настолько поехавший?
Где уж мне до вас, дяденька.

Thread
launch_thread(Iterable<String> v, int iterations) {
    // Здесь компилятор запрещает модифицировать v.
    return new Thread(()-> {
        // Здесь компилятор запрещает модифицировать v.
        var l = v.stream()
            .limit(iterations)
            .mapToInt(String::length)
            .sum();
        System.out.println("iterations: " + iterations + ", l=" + l);
    });
}

Попробуйте этом коде просто так модифицировать v.

Да, там есть нюанс с Iterator, но это, к сожалению, исторический казус и плохое легаси. collections api в jdk не идеальный. Но это проблема конкретно JDK, а не ЯП.

s> ·>зато в c++ молитва const позволяет писать правильный код.

s> Да.
Ок. Если тебе помогает, можешь молиться в сердце своём. А const в ЯП впендюривать не обязательно.

s> ·>У тебя опять память подводит. Есть final, record и даже sealed интерфейсы.

s> Ну и как с помощью этого всего сделать из HashMap неизменяемый HashMap? Ну вот был HashMap, требуется сделать так, чтобы его модифицировать нельзя было.
Если в типе изначально не предусмотрена константность (не предусмотрены методы с const), то ты нихрена не сделаешь. В HashMap не предусмотрена константность.
Однако, объект HashMap можно сделать неизменяемым, например, с помощью Collections.unmodifiableMap.

s> ·>Как и const. Всё верно.

Для клинических идиотов повторю еще раз:
void mutate(ArrayList<String> v);

Iterable<String> immutable_value = new ArrayList<>(...);
mutate(immutable_value);

Попробуйте заставить компилятор принять у вас такой код.

s> ·>И что? У тебя проблемы с логикой. Достаточно одного опровергающего примера и похрен на миллион подтверждающих.

s> Хде, хде, блин, этот опровергающий пример? Пока ни одного не было. Были примеры с наличием const-ссылок, но отсутствием const-объектов.
Именно. И это никак компилятором не проверяется. Всё на честном слове — не забыл (не смог, т.к. его надо было собрать из кусочков, например) поставить const на объекте — сработает. Не смог — не сработает. И компилятор будет молчать.

s> ·>Ровно это же можно сделать с иммутабельными типами.

s> Еще раз для клинических идиотов: дополнительные сущности, которые программист должен делать вручную (хоть и посредством IDE) без какого-либо контроля со стороны компилятора.
Описывать const-методы программист тоже должен делать вручную. Т.е. решить какие вещи в данном типе могут, а какие не могут быть const.

s> ·>В твоём примере показано

s> Да, было показано:
s>
s> int main() {
s>     const vector_of_string immutable_data{ "Hello"s, "World"s }; // Все, гарантии появились.
s>

Вопрос был: "как же константность объекта там _гарантированно_ появится?" Откуда в данной строчке будет гарантированно стоять модификатор const?