Читаем Программирование на языке Ruby полностью

• В качестве примера рассмотрим строку str и образец (регулярное выражение) pat, с которым эта строка успешно сопоставляется.

Выражение str =~ pat истинно, как в языке Perl. Поскольку Ruby определяет противоположную семантику оператора =~ в классе Regexp, можно также сказать, что выражение pat =~ str истинно. Следуя той же логике, мы обнаруживаем, что истинно и pat === str (исходя из того, как определен оператор === в классе Regexp). Однако выражение str === pat истинным не является. А значит, фрагмент

case "Hello"

 when /Hell/

  puts "Есть соответствие."

 else

  puts "Нет соответствия."

end

делает не то же самое, что фрагмент

case /Hell/

 when "Hello"

  puts "Есть соответствие."

 else

  puts "Нет соответствия."

end

Если это вас смущает, просто постарайтесь запомнить. А если не смущает, тем лучше!

• Программисты, привыкшие к С, могут быть озадачены отсутствием предложений break в ветвях case. Такое использование break в Ruby необязательно (и недопустимо). Связано это с тем, что «проваливание» редко бывает желательно при многопутевом ветвлении. В конце каждой ветви when имеется неявный переход на конец предложения case. В этом отношении Ruby напоминает Pascal.

• Значения в каждой ветви case могут быть произвольными. На типы никаких ограничений не налагается. Они не обязаны быть константами; допускаются и переменные, и сложные выражения. Кроме того, в ветви может проверяться попадание в диапазон.

• В ветвях case могут находиться пустые действия (пустые предложения). Значения в разных ветвях не обязательно должны быть уникальными — допускаются перекрытия, например:

case x

 when 0

 when 1..5

  puts "Вторая ветвь"

 when 5..10

  puts "Третья ветвь"

 else

  puts "Четвертая ветвь"

end

Если x принимает значение 0, ничего не делается. Для значения 5 печатается строка «Вторая ветвь» — несмотря на то что 5 удовлетворяет и условию в третьей ветви.

• Перекрытие ветвей допускается потому, что они вычисляются в строгом порядке и выполняется закорачивание. Иными словами, если вычисление выражения в какой-то ветви оказалось успешным, то следующие ветви не вычисляются. Поэтому не стоит помещать в ветви case выражения, в которых вызываются методы с побочными эффектами. (Впрочем, такие вызовы в любом случае сомнительны). Имейте также в виду, что такое поведение может замаскировать ошибки, которые произошли бы во время выполнения, если бы выражение вычислялось. Например:

case x

 when 1..10

  puts "Первая ветвь"

 when foobar # Возможен побочный эффект?

  puts "Вторая ветвь"

 when 5/0      # Деление на нуль!

  puts "Третья ветвь"

 else

  puts "Четвертая ветвь"

end

Если x находится в диапазоне от 1 до 10, то метод foobar не вызывается, а выражение 5/0 (которое, естественно, привело бы к ошибке) не вычисляется.

<p>1.5.4. Рубизмы и идиомы</p>

Материал в этом разделе во многом пересекается с изложенным выше. Но не задумывайтесь особо, почему мы решили разбить его именно таким образом. Просто многие вещи трудно точно классифицировать и организовать единственно правильным образом. Мы ставили себе задачу представить информацию в удобном для усвоения виде.

Ruby проектировался как непротиворечивый и ортогональный язык. Но вместе с тем это сложный язык, в котором есть свои идиомы и странности. Некоторые из них мы обсудим ниже.

• С помощью ключевого слова alias можно давать глобальным переменным и методам альтернативные имена (синонимы).

• Пронумерованные глобальные переменные $1, $2, $3 и т.д. не могут иметь синонимов.

• Мы не рекомендуем использовать «специальные переменные» $=, $_, $/ и им подобные. Иногда они позволяют написать более компактный код, но при этом он не становится более понятным. Поэтому в данной книге мы прибегаем к ним очень редко, что и вам рекомендуем.

• Не путайте операторы диапазона .. и ... — первый включает верхнюю границу, второй исключает. Так, диапазон 5..10 включает число 10, а диапазон 5...10 — нет.

• С диапазонами связана одна мелкая деталь, которая может вызвать путаницу. Если дан диапазон m..n, то метод end вернет конечную его точку n, равно как и его синоним last. Но те же методы возвращают значение n и для диапазона m...n, хотя n не включается в него. Чтобы различить эти две ситуации, предоставляется метод end_excluded?.

• Не путайте диапазоны с массивами. Следующие два присваивания абсолютно различны:

x = 1..5

x = [1, 2, 3, 4, 5]

Однако есть удобный метод to_a для преобразования диапазона в массив. (Во многих других типах тоже есть такой метод.)

Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT