Отметим, что здесь соблюдается стандартное соглашение о заключении многострочного блока в операторные скобки
do-end
. Круглые скобки обязательны из-за особенностей синтаксического
анализатора Ruby. Можно было бы, конечно, вместо этого поставить фигурные скобки.
Вот что будет напечатано в результате выполнения этого кода:
line prog.rb:13 false/
call prog.rb:1 Object/meth
line prog.rb:2 Object/meth
line prog.rb:3 Object/meth
c-call prog.rb:3 Range/each
line prog.rb:4 Object/meth
c-call prog.rb:4 Fixnum/+
c-return prog.rb:4 Fixnum/+
line prog.rb:4 Object/meth
c-call prog.rb:4 Fixnum/+
c-return prog.rb:4 Fixnum/+
c-return prog.rb:4 Range/each
line prog.rb:6 Object/meth
return prog.rb:6 Object/meth
С этим методом тесно связан метод
Kernel#trace_var
, который вызывает указанный блок при каждом присваивании значения глобальной переменной.
Предположим, что вам нужно извне протрассировать выполнение программы в целях отладки. Проще всего воспользоваться для этого библиотекой
tracer
. Пусть имеется следующая программа
prog.rb
:
def meth(n)
(1..n).each {|i| puts i}
end
meth(3)
Можно запустить
tracer
из командной строки:
% ruby -r tracer prog.rb
#0:prog.rb:1::-: def meth(n)
#0:prog.rb:1:Module:>: def meth(n)
#0:prog.rb:1:Module:<: def meth(n)
#0:prog.rb:8::-: meth(2)
#0:prog.rb:1:Object:>: def meth(n)
#0:prog.rb:2:Object:-: sum = 0
#0:prog.rb:3:Object:-: for i in 1..n
#0:prog.rb:3:Range:>: for i in 1..n
#0:prog.rb:4:Object:-: sum += i
#0:prog.rb:4:Fixnum:>: sum += i
#0:prog.rb:4:Fixnum:<: sum += i
#0:prog.rb:4:Object:-: sum += i
#0:prog.rb:4:Fixnum:>: sum += i
#0:prog.rb:4:Fixnum:<: sum += i
#0:prog.rb:4:Range:<: sum += i
#0:prog.rb:6:Object:-: sum
#0:prog.rb:6:Object:<: sum
Программа
tracer
выводит номер потока, имя файла и номер строки, имя класса, тип события и исполняемую строку исходного текста трассируемой программы. Бывают следующие типы событий:
'-'
— исполняется строка исходного текста,
'>'
— вызов,
'<'
—
возврат,
'С'
— класс,
'Е'
— конец. (Если вы автоматически включите эту библиотеку с помощью переменной окружения
RUBYOPT
или каким-то иным способом, то может быть напечатано много тысяч строк.)
11.3.11. Обход пространства объектов
Система исполнения Ruby должна отслеживать все известные объекты (хотя бы для того, чтобы убрать мусор, когда на объект больше нет ссылок). Информацию о них можно получить с помощью метода
ObjectSpace.each_object
.
ObjectSpace.each_object do |obj|
printf "%20s: %s\n", obj.class, obj.inspect
end
Если задать класс или модуль в качестве параметра
each_object
, то будут возвращены лишь объекты указанного типа.
Модуль Object Space полезен также для определения чистильщиков объектов (см. раздел 11.3.14).
11.3.12. Обработка вызовов несуществующих методов
Иногда бывают полезны классы, отвечающие на вызовы произвольных методов. Например, для того чтобы обернуть обращения к внешним программам в класс, который представляет каждое такое обращение как вызов метода. Заранее имена всех программ вы не знаете, поэтому написать определения всех методов при создании класса не получится. На помощь приходит метод
Object#method_missing
. Если объект Ruby получает сообщение для метода, который в нем не реализован, то вызывается метод
method_missing
. Этим можно воспользоваться для превращения ошибки в обычный вызов метода. Реализуем класс, обертывающий команды операционной системы:
class CommandWrapper
def method_missing(method, *args)
system (method.to_s, *args)
end
end
cw = CommandWrapper.new
cw.date # Sat Apr 28 22:50:11 CDT 2001
cw.du '-s', '/tmp' # 166749 /tmp
Первый параметр метода
method_missing
— имя вызванного метода (которое не удалось найти). Остальные параметры — все то, что было передано при вызове этого метода.
Если написанная вами реализация
method_missing
не хочет обрабатывать конкретный вызов, она должна вызвать
super
, а не возбуждать исключение. Тогда методы
method_missing
в суперклассах получат возможность разобраться с ситуацией. В конечном счете будет вызван
method_missing
, определенный в классе
Object
, который и возбудит исключение.
11.3.13. Отслеживание изменений в определении класса или объекта
А зачем, собственно? Кому интересны изменения, которым подвергался класс?
Одна возможная причина — желание следить за состоянием выполняемой программы на Ruby. Быть может, мы реализуем графический отладчик, который должен обновлять список методов, добавляемых «на лету».
Другая причина: мы хотим вносить соответствующие изменения в другие классы. Например, мы разрабатываем модуль, который можно включить в определение любого класса. С момента включения будут трассироваться любые обращения к методам этого класса. Что-то в этом роде: