Comments 18
Прошедшие скринкасты можно где нибудь скачать?
Поддерживаю Ro Onа.Было бы интересно посмотреть.
А что делать тем, кто не пользуется Windows (софт для голосового общения, насколько я понял, только для Windows)? У меня жена хотела бы присоединиться к курсам, но у нас компьютеры только с MacOS, а в VirtualBox'овой Windows XP клиент cde.ru не запускается (хотя устанавливается без ошибок).
> Поняли, почему в Ruby нет оператора ++
Кстати, а почему?
Кстати, а почему?
чтобы небыло путаницы. зато вмест for i=1 i<10 i++ легко написать
10.times
или
1.upto(10)
поэтому++ уже не нужен.
10.times
или
1.upto(10)
поэтому++ уже не нужен.
потому что Fixnum может сменится на Bignum, и преобразование объекта на месте невозможно
Инкремент в префиксной форме является сахаром для операции += 1.
По сути своей, ++ содержит в себе неявное присваивание в любых формах. Проблем с преобразованием нет — мы получаем уже другой объект, а не модифицируем старый. Отказ от ++ скорее не вяжется с философией руби по возможности возвращать последнее вычисленное значение (а в случае использования постфиксной формы инкремента в си-подобных языках возвращается исходное значение). Вот, кстати, matz пишет об этом redmine.ruby-lang.org/issues/show/1432
По сути своей, ++ содержит в себе неявное присваивание в любых формах. Проблем с преобразованием нет — мы получаем уже другой объект, а не модифицируем старый. Отказ от ++ скорее не вяжется с философией руби по возможности возвращать последнее вычисленное значение (а в случае использования постфиксной формы инкремента в си-подобных языках возвращается исходное значение). Вот, кстати, matz пишет об этом redmine.ruby-lang.org/issues/show/1432
* По сути своей, ++ содержит в себе неявное присваивание в любых формах
— ну вообще говоря, ++ ассоциируется не с присваиванием, а с изменением объекта (в с++ в 99% этот оператор используют для смещения итераторов). А matz пишет про assignment, так как в Руби про потенциальный новый оператор ++x сложно думать иначе как (x+=1)
* Инкремент в префиксной форме является сахаром для операции += 1
— О каком языке идет речь? Полагаю что, о Си или С++ или о Java.
— Си: оператор ++ можно назвать сахаром для +=1, но суть в том, что там он не может менять типа переменной.
— С++: оператор ++ для новых классов обычно определяют так, что он меняет объект на месте и, конечно, не меняет класса объекта (оператор += можно определить независимо от ++ как захочется, в том числе, этот оператор может возвращать объект нового класса). И конечно, в Си++ оператор ++ не является сахаром для +=1.
— Проблем с преобразованием, а точнее, с созданием нового объекта нового класса, конечно, нет. Просто никто не ожидает, что оператор ++ будет создавать новый объект. Никто не ожидает, что x++ может сменить класс x, так как в других языках так не делают. И этой проблемы не было бы, если бы в Руби был один класс Integer===Bignum, и не было бы Fixnum и Bignum. Объекты Bignum действительно на месте можно увеличить на 1. Именно поэтому я и написал то, что написал. Укажите пожалуйста, какие идеологические проблемы были бы с введением оператора ++, если бы был один класс для всех целых чисел.
* Отказ от ++ скорее не вяжется с философией руби по возможности возвращать последнее вычисленное значение (а в случае использования постфиксной формы инкремента в си-подобных языках возвращается исходное значение)
— никакой неувязки бы не было; можно было бы реализовать и постфиксную и префиксную форму оператора с правильным возвращаемым значением. Чем вас так напугало, то что последнее вычисленное значение является возвращаемым значением метода?
— ну вообще говоря, ++ ассоциируется не с присваиванием, а с изменением объекта (в с++ в 99% этот оператор используют для смещения итераторов). А matz пишет про assignment, так как в Руби про потенциальный новый оператор ++x сложно думать иначе как (x+=1)
* Инкремент в префиксной форме является сахаром для операции += 1
— О каком языке идет речь? Полагаю что, о Си или С++ или о Java.
— Си: оператор ++ можно назвать сахаром для +=1, но суть в том, что там он не может менять типа переменной.
— С++: оператор ++ для новых классов обычно определяют так, что он меняет объект на месте и, конечно, не меняет класса объекта (оператор += можно определить независимо от ++ как захочется, в том числе, этот оператор может возвращать объект нового класса). И конечно, в Си++ оператор ++ не является сахаром для +=1.
— Проблем с преобразованием, а точнее, с созданием нового объекта нового класса, конечно, нет. Просто никто не ожидает, что оператор ++ будет создавать новый объект. Никто не ожидает, что x++ может сменить класс x, так как в других языках так не делают. И этой проблемы не было бы, если бы в Руби был один класс Integer===Bignum, и не было бы Fixnum и Bignum. Объекты Bignum действительно на месте можно увеличить на 1. Именно поэтому я и написал то, что написал. Укажите пожалуйста, какие идеологические проблемы были бы с введением оператора ++, если бы был один класс для всех целых чисел.
* Отказ от ++ скорее не вяжется с философией руби по возможности возвращать последнее вычисленное значение (а в случае использования постфиксной формы инкремента в си-подобных языках возвращается исходное значение)
— никакой неувязки бы не было; можно было бы реализовать и постфиксную и префиксную форму оператора с правильным возвращаемым значением. Чем вас так напугало, то что последнее вычисленное значение является возвращаемым значением метода?
Я писал в общем, не привязываясь к конкретному языку — не считаю что вопрос реализации присваивания в Эф Шарпе или Коммон-лиспе играет особую роль. В си-плюс особенно — там и разговора нет, мы там способны наделать макросов и как угодно писать. Но, пожалуй, добавлю, что если префиксный ++ для числа и += 1 не взаимозаменяемы, то скорее всего код содержит ошибку в своей семантике.
Не важно с чем ассоциируется ++, важно то, что было одно значение, а стало другое с тем же именем, в той же области видимости. Вот и всё, а остальное зависит от реализации.
* x++ может сменить класс x, так как в других языках так не делают
В php :) горячо любимом. Там люто целое становится float'ом, если не влезло. В результате выполнения операции.
+= Тоже может заменить значение бывшее Fix в Big если так случится.
winnie@tsundere:~$ irb
ruby-1.9.2-head > i = 2 ** (666.size * 8 — 2) — 1
=> 4611686018427387903
ruby-1.9.2-head > i.class
=> Fixnum
ruby-1.9.2-head > j = (i += 1) + 10
=> 4611686018427387914
ruby-1.9.2-head > i.class
=> Bignum
Это не повод убрать += из-за того, что в C++ так не делают, извините.
* Укажите пожалуйста, какие идеологические проблемы были бы с введением оператора ++, если бы был один класс для всех целых чисел.
Почти никаких. Matz'у предложили, он отказался. Мне это нравится.
Вот привёл примеров немного — все эти действия вернули объекты. И значения переменных равны результатам.
LEFT VAlUE = RIGHT VALUE
winnie@tsundere:~$ irb
ruby-1.9.2-head > i = 10 + 2
=> 12
ruby-1.9.2-head > j = 10 ** 2
=> 100
ruby-1.9.2-head > d = i — 1
=> 11
ruby-1.9.2-head > m = (i += 1) — 2
=> 11
Если бы мы добавили в руби, скажем, постфиксный инкремент, то вышло бы так
i = 10
i++
Результат выражения i++ — десятка. А значение i после его выполнения — 11. В этом и есть некоторое неудобство.
Вот, например, такие дела в php, где есть си-стайл инкремент.
php > $i = 10;
php > echo $i++;
10
php > echo $i;
11
Я могу написать отсебятины вроде той, что многие программисты зря обращают внимание на префиксные и постфиксные формы в ущерб читаемости, но думаю, что это никому не интересно :)
* Чем вас так напугало, то что последнее вычисленное значение является возвращаемым значением метода?
Меня не напугало. Мне это нравится. Мне любо почти не писать return. Я всем грю: «Смотри ретурн не нужно писать».
Не важно с чем ассоциируется ++, важно то, что было одно значение, а стало другое с тем же именем, в той же области видимости. Вот и всё, а остальное зависит от реализации.
* x++ может сменить класс x, так как в других языках так не делают
В php :) горячо любимом. Там люто целое становится float'ом, если не влезло. В результате выполнения операции.
+= Тоже может заменить значение бывшее Fix в Big если так случится.
winnie@tsundere:~$ irb
ruby-1.9.2-head > i = 2 ** (666.size * 8 — 2) — 1
=> 4611686018427387903
ruby-1.9.2-head > i.class
=> Fixnum
ruby-1.9.2-head > j = (i += 1) + 10
=> 4611686018427387914
ruby-1.9.2-head > i.class
=> Bignum
Это не повод убрать += из-за того, что в C++ так не делают, извините.
* Укажите пожалуйста, какие идеологические проблемы были бы с введением оператора ++, если бы был один класс для всех целых чисел.
Почти никаких. Matz'у предложили, он отказался. Мне это нравится.
Вот привёл примеров немного — все эти действия вернули объекты. И значения переменных равны результатам.
LEFT VAlUE = RIGHT VALUE
winnie@tsundere:~$ irb
ruby-1.9.2-head > i = 10 + 2
=> 12
ruby-1.9.2-head > j = 10 ** 2
=> 100
ruby-1.9.2-head > d = i — 1
=> 11
ruby-1.9.2-head > m = (i += 1) — 2
=> 11
Если бы мы добавили в руби, скажем, постфиксный инкремент, то вышло бы так
i = 10
i++
Результат выражения i++ — десятка. А значение i после его выполнения — 11. В этом и есть некоторое неудобство.
Вот, например, такие дела в php, где есть си-стайл инкремент.
php > $i = 10;
php > echo $i++;
10
php > echo $i;
11
Я могу написать отсебятины вроде той, что многие программисты зря обращают внимание на префиксные и постфиксные формы в ущерб читаемости, но думаю, что это никому не интересно :)
* Чем вас так напугало, то что последнее вычисленное значение является возвращаемым значением метода?
Меня не напугало. Мне это нравится. Мне любо почти не писать return. Я всем грю: «Смотри ретурн не нужно писать».
Лектор и его оборудование были не готовы к Хабраэффекту. :)
Sign up to leave a comment.
Обучение программированию на Ruby — занятия продолжаются