💡 Инструкция: Выберите один ответ из пяти. Время — 70 минут. У каждого задания ровно один правильный вариант. Фрагменты рассчитаны на Ruby 4.0.6; задания Rails — на Rails 8.1.3. После завершения откроются общий процент, 5 тематических результатов и разбор всех ответов.
Вопрос 1 из 25
Что произойдёт после последней строки в примере по теме «Внешний итератор Enumerator»? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Внешний итератор Enumerator Копировать
# Проследите выполнение и выберите точный результат.
enum = [10, 20, 30].each
p enum.next
p enum.next
enum.rewind
p enum.next
После полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`. Это объясняется тем, что Enumerator отделяет получение следующего элемента от самого источника; `next` продвигает внутреннюю позицию, а `rewind` возвращает её к началу, если источник это поддерживает.
Два вызова `next` дают 10 и 20, после `rewind` следующий вызов снова возвращает 10. Это объясняется тем, что Enumerator отделяет получение следующего элемента от самого источника; `next` продвигает внутреннюю позицию, а `rewind` возвращает её к началу, если источник это поддерживает.
Два вызова `next` дают 10 и 20, после `rewind` следующий вызов снова возвращает 10. Это объясняется тем, что ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Enumerator выдаёт 1, 4 и 9, после чего `to_a` заканчивается без дополнительного значения. Это объясняется тем, что Enumerator отделяет получение следующего элемента от самого источника; `next` продвигает внутреннюю позицию, а `rewind` возвращает её к началу, если источник это поддерживает.
Два вызова `next` дают 10 и 20, после `rewind` следующий вызов снова возвращает 10. Это объясняется тем, что собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности.
Вопрос 2 из 25
Проследите выполнение фрагмента. Какой результат верен для темы «Протокол обхода each»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Ruby Ruby — Протокол обхода each Копировать
# Проследите выполнение и выберите точный результат.
class Evens
include Enumerable
def each
return enum_for(__method__) unless block_given?
yield 2
yield 4
self
end
end
p Evens.new.each.to_a
После полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`. Причина такого результата: метод `each` должен передавать элементы блоку и обычно возвращать исходный объект; без блока принято возвращать Enumerator.
Для получения двух результатов блок `map` вызывается только столько раз, сколько нужно после фильтрации. Причина такого результата: метод `each` должен передавать элементы блоку и обычно возвращать исходный объект; без блока принято возвращать Enumerator.
Класс выдаёт два значения, а вызов без блока возвращает Enumerator, из которого `to_a` получает `[2, 4]`. Причина такого результата: Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми.
Класс выдаёт два значения, а вызов без блока возвращает Enumerator, из которого `to_a` получает `[2, 4]`. Причина такого результата: метод `each` должен передавать элементы блоку и обычно возвращать исходный объект; без блока принято возвращать Enumerator.
Класс выдаёт два значения, а вызов без блока возвращает Enumerator, из которого `to_a` получает `[2, 4]`. Причина такого результата: ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Вопрос 3 из 25
Что покажет выполнение этого фрагмента из раздела «Ленивость»? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Ленивость Копировать
# Проследите выполнение и выберите точный результат.
seen = 0
result = (1..).lazy
.map { |n| seen += 1; n * 2 }
.select { |n| n > 4 }
.first(2)
p [result, seen]
Для получения двух результатов блок `map` вызывается только столько раз, сколько нужно после фильтрации. Такой итог следует из правила: Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми.
Для получения двух результатов блок `map` вызывается только столько раз, сколько нужно после фильтрации. Такой итог следует из правила: собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности.
После полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`. Такой итог следует из правила: ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Для получения двух результатов блок `map` вызывается только столько раз, сколько нужно после фильтрации. Такой итог следует из правила: ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Класс выдаёт два значения, а вызов без блока возвращает Enumerator, из которого `to_a` получает `[2, 4]`. Такой итог следует из правила: ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Вопрос 4 из 25
Какая трассировка кода по теме «Собственный итератор» не теряет важную деталь? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Ruby Ruby — Собственный итератор Копировать
# Проследите выполнение и выберите точный результат.
squares = Enumerator.new do |y|
1.upto(3) { |n| y << n * n }
end
p squares.to_a
Два вызова `next` дают 10 и 20, после `rewind` следующий вызов снова возвращает 10. Механизм результата таков: собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности.
Enumerator выдаёт 1, 4 и 9, после чего `to_a` заканчивается без дополнительного значения. Механизм результата таков: ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Enumerator выдаёт 1, 4 и 9, после чего `to_a` заканчивается без дополнительного значения. Механизм результата таков: Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми.
Enumerator выдаёт 1, 4 и 9, после чего `to_a` заканчивается без дополнительного значения. Механизм результата таков: собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности.
После полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`. Механизм результата таков: собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности.
Вопрос 5 из 25
Как изменится состояние программы после выполнения кода по теме «Пограничные случаи»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Ruby Ruby — Пограничные случаи Копировать
# Проследите выполнение и выберите точный результат.
enum = %w[a b].each
p enum.next
p enum.next
begin
enum.next
rescue StopIteration => e
p e.result
end
Для получения двух результатов блок `map` вызывается только столько раз, сколько нужно после фильтрации. Наблюдение согласуется с тем, что Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми.
После полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`. Наблюдение согласуется с тем, что Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми.
После полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`. Наблюдение согласуется с тем, что ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Класс выдаёт два значения, а вызов без блока возвращает Enumerator, из которого `to_a` получает `[2, 4]`. Наблюдение согласуется с тем, что Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми.
После полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`. Наблюдение согласуется с тем, что метод `each` должен передавать элементы блоку и обычно возвращать исходный объект; без блока принято возвращать Enumerator.
Вопрос 6 из 25
Какое скрытое условие делает фрагмент «Внешний итератор Enumerator» хрупким? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Внешний итератор Enumerator Копировать
# Обычный запуск проходит. Найдите скрытый риск.
enum = [10, 20, 30].each
p enum.next
p enum.next
enum.rewind
p enum.next
Один Enumerator хранит состояние обхода; совместное использование разными потребителями приводит к пропускам и зависимости от порядка вызовов. Причина — ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Один Enumerator хранит состояние обхода; совместное использование разными потребителями приводит к пропускам и зависимости от порядка вызовов. Причина — собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности.
Генератор без условия завершения безопасен только вместе с ленивым ограничителем; прямой `to_a` на нём никогда не закончится. Причина — Enumerator отделяет получение следующего элемента от самого источника; `next` продвигает внутреннюю позицию, а `rewind` возвращает её к началу, если источник это поддерживает.
Вставка `force`, `to_a`, `sort` или `group_by` материализует поток и может превратить ограниченную задачу в обработку всего источника. Причина — Enumerator отделяет получение следующего элемента от самого источника; `next` продвигает внутреннюю позицию, а `rewind` возвращает её к началу, если источник это поддерживает.
Один Enumerator хранит состояние обхода; совместное использование разными потребителями приводит к пропускам и зависимости от порядка вызовов. Причина — Enumerator отделяет получение следующего элемента от самого источника; `next` продвигает внутреннюю позицию, а `rewind` возвращает её к началу, если источник это поддерживает.
Вопрос 7 из 25
Где в показанном решении «Протокол обхода each» скрыт дефект, который проявится не на каждом входе? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Протокол обхода each Копировать
# Обычный запуск проходит. Найдите скрытый риск.
class Evens
include Enumerable
def each
return enum_for(__method__) unless block_given?
yield 2
yield 4
self
end
end
p Evens.new.each.to_a
Генератор без условия завершения безопасен только вместе с ленивым ограничителем; прямой `to_a` на нём никогда не закончится. Этот риск связан с тем, что метод `each` должен передавать элементы блоку и обычно возвращать исходный объект; без блока принято возвращать Enumerator.
Самодельный `each`, который без блока сразу вызывает `yield`, нарушает протокол Enumerable и поднимает LocalJumpError. Этот риск связан с тем, что ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Самодельный `each`, который без блока сразу вызывает `yield`, нарушает протокол Enumerable и поднимает LocalJumpError. Этот риск связан с тем, что метод `each` должен передавать элементы блоку и обычно возвращать исходный объект; без блока принято возвращать Enumerator.
Код, который сначала делает `count`, а затем `map` по одноразовому источнику, может второй раз получить пустой поток. Этот риск связан с тем, что метод `each` должен передавать элементы блоку и обычно возвращать исходный объект; без блока принято возвращать Enumerator.
Самодельный `each`, который без блока сразу вызывает `yield`, нарушает протокол Enumerable и поднимает LocalJumpError. Этот риск связан с тем, что Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми.
Вопрос 8 из 25
Какой рабочий сбой вероятнее всего связан именно с механизмом «Ленивость»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Ruby Ruby — Ленивость Копировать
# Обычный запуск проходит. Найдите скрытый риск.
seen = 0
result = (1..).lazy
.map { |n| seen += 1; n * 2 }
.select { |n| n > 4 }
.first(2)
p [result, seen]
Генератор без условия завершения безопасен только вместе с ленивым ограничителем; прямой `to_a` на нём никогда не закончится. Уязвимое место возникает потому, что ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Вставка `force`, `to_a`, `sort` или `group_by` материализует поток и может превратить ограниченную задачу в обработку всего источника. Уязвимое место возникает потому, что собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности.
Вставка `force`, `to_a`, `sort` или `group_by` материализует поток и может превратить ограниченную задачу в обработку всего источника. Уязвимое место возникает потому, что ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Один Enumerator хранит состояние обхода; совместное использование разными потребителями приводит к пропускам и зависимости от порядка вызовов. Уязвимое место возникает потому, что ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Вставка `force`, `to_a`, `sort` или `group_by` материализует поток и может превратить ограниченную задачу в обработку всего источника. Уязвимое место возникает потому, что Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми.
Вопрос 9 из 25
Обычный сценарий проходит. Какой риск остаётся в теме «Собственный итератор»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Собственный итератор Копировать
# Обычный запуск проходит. Найдите скрытый риск.
squares = Enumerator.new do |y|
1.upto(3) { |n| y << n * n }
end
p squares.to_a
Генератор без условия завершения безопасен только вместе с ленивым ограничителем; прямой `to_a` на нём никогда не закончится. К такому сбою приводит правило: Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми.
Самодельный `each`, который без блока сразу вызывает `yield`, нарушает протокол Enumerable и поднимает LocalJumpError. К такому сбою приводит правило: собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности.
Код, который сначала делает `count`, а затем `map` по одноразовому источнику, может второй раз получить пустой поток. К такому сбою приводит правило: собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности.
Генератор без условия завершения безопасен только вместе с ленивым ограничителем; прямой `to_a` на нём никогда не закончится. К такому сбою приводит правило: собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности.
Генератор без условия завершения безопасен только вместе с ленивым ограничителем; прямой `to_a` на нём никогда не закончится. К такому сбою приводит правило: ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Вопрос 10 из 25
Почему успешный пример ещё не доказывает надёжность решения «Пограничные случаи»? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Ruby Ruby — Пограничные случаи Копировать
# Обычный запуск проходит. Найдите скрытый риск.
enum = %w[a b].each
p enum.next
p enum.next
begin
enum.next
rescue StopIteration => e
p e.result
end
Код, который сначала делает `count`, а затем `map` по одноразовому источнику, может второй раз получить пустой поток. Источник риска: ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено.
Генератор без условия завершения безопасен только вместе с ленивым ограничителем; прямой `to_a` на нём никогда не закончится. Источник риска: Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми.
Код, который сначала делает `count`, а затем `map` по одноразовому источнику, может второй раз получить пустой поток. Источник риска: Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми.
Код, который сначала делает `count`, а затем `map` по одноразовому источнику, может второй раз получить пустой поток. Источник риска: метод `each` должен передавать элементы блоку и обычно возвращать исходный объект; без блока принято возвращать Enumerator.
Самодельный `each`, который без блока сразу вызывает `yield`, нарушает протокол Enumerable и поднимает LocalJumpError. Источник риска: Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми.
Вопрос 11 из 25
Как сформулировать правило блока «Внешний итератор Enumerator» без лишних обещаний? Верный вариант не содержит частично правильной подмены причины или следствия.
Ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено. Поэтому два вызова `next` дают 10 и 20, после `rewind` следующий вызов снова возвращает 10.
Собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности. Поэтому два вызова `next` дают 10 и 20, после `rewind` следующий вызов снова возвращает 10.
Enumerator отделяет получение следующего элемента от самого источника; `next` продвигает внутреннюю позицию, а `rewind` возвращает её к началу, если источник это поддерживает. Поэтому после полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`.
Enumerator отделяет получение следующего элемента от самого источника; `next` продвигает внутреннюю позицию, а `rewind` возвращает её к началу, если источник это поддерживает. Поэтому Enumerator выдаёт 1, 4 и 9, после чего `to_a` заканчивается без дополнительного значения.
Enumerator отделяет получение следующего элемента от самого источника; `next` продвигает внутреннюю позицию, а `rewind` возвращает её к началу, если источник это поддерживает. Поэтому два вызова `next` дают 10 и 20, после `rewind` следующий вызов снова возвращает 10.
Вопрос 12 из 25
Почему показанный фрагмент «Протокол обхода each» ведёт себя именно так? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Метод `each` должен передавать элементы блоку и обычно возвращать исходный объект; без блока принято возвращать Enumerator. Из этого следует, что после полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`.
Метод `each` должен передавать элементы блоку и обычно возвращать исходный объект; без блока принято возвращать Enumerator. Из этого следует, что для получения двух результатов блок `map` вызывается только столько раз, сколько нужно после фильтрации.
Ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено. Из этого следует, что класс выдаёт два значения, а вызов без блока возвращает Enumerator, из которого `to_a` получает `[2, 4]`.
Метод `each` должен передавать элементы блоку и обычно возвращать исходный объект; без блока принято возвращать Enumerator. Из этого следует, что класс выдаёт два значения, а вызов без блока возвращает Enumerator, из которого `to_a` получает `[2, 4]`.
Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми. Из этого следует, что класс выдаёт два значения, а вызов без блока возвращает Enumerator, из которого `to_a` получает `[2, 4]`.
Вопрос 13 из 25
Какое правило Ruby или Rails объясняет поведение в теме «Ленивость»? Правильным считается только полностью согласованное утверждение.
Собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности. Наблюдаемое следствие: для получения двух результатов блок `map` вызывается только столько раз, сколько нужно после фильтрации.
Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми. Наблюдаемое следствие: для получения двух результатов блок `map` вызывается только столько раз, сколько нужно после фильтрации.
Ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено. Наблюдаемое следствие: для получения двух результатов блок `map` вызывается только столько раз, сколько нужно после фильтрации.
Ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено. Наблюдаемое следствие: класс выдаёт два значения, а вызов без блока возвращает Enumerator, из которого `to_a` получает `[2, 4]`.
Ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено. Наблюдаемое следствие: после полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`.
Вопрос 14 из 25
Как сформулировать правило блока «Собственный итератор» без лишних обещаний? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми. Именно поэтому Enumerator выдаёт 1, 4 и 9, после чего `to_a` заканчивается без дополнительного значения.
Ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено. Именно поэтому Enumerator выдаёт 1, 4 и 9, после чего `to_a` заканчивается без дополнительного значения.
Собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности. Именно поэтому Enumerator выдаёт 1, 4 и 9, после чего `to_a` заканчивается без дополнительного значения.
Собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности. Именно поэтому после полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`.
Собственный генератор удобно строить через `Enumerator.new`, вызывая `yielder << value`; завершение блока означает окончание последовательности. Именно поэтому два вызова `next` дают 10 и 20, после `rewind` следующий вызов снова возвращает 10.
Вопрос 15 из 25
Какой механизм объясняет и обычный, и граничный сценарий «Пограничные случаи»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми. Это правило даёт такой результат: после полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`.
Метод `each` должен передавать элементы блоку и обычно возвращать исходный объект; без блока принято возвращать Enumerator. Это правило даёт такой результат: после полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`.
Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми. Это правило даёт такой результат: класс выдаёт два значения, а вызов без блока возвращает Enumerator, из которого `to_a` получает `[2, 4]`.
Ленивый Enumerator выполняет операции по требованию; ограничивающий потребитель определяет, сколько элементов реально будет вычислено. Это правило даёт такой результат: после полного обхода Enumerator повторный `next` поднимает StopIteration, пока не вызван `rewind`.
Enumerable не обещает повторный обход для любого источника: поток, сокет или состояние внешнего Enumerator могут быть одноразовыми. Это правило даёт такой результат: для получения двух результатов блок `map` вызывается только столько раз, сколько нужно после фильтрации.
Вопрос 17 из 25
Что следует изменить в решении «Протокол обхода each», чтобы закрыть исходный риск? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Ruby Ruby — Протокол обхода each Копировать
# Выберите изменение, которое исправляет причину.
class Evens
include Enumerable
def each
return enum_for(__method__) unless block_given?
yield 2
yield 4
self
end
end
p Evens.new.each.to_a
Следовать протоколу `return enum_for(__method__) unless block_given?` и тестировать возврат самого объекта при обходе с блоком. Это изменение устраняет проблему: генератор без условия завершения безопасен только вместе с ленивым ограничителем; прямой `to_a` на нём никогда не закончится.
Следовать протоколу `return enum_for(__method__) unless block_given?` и тестировать возврат самого объекта при обходе с блоком. Это изменение устраняет проблему: самодельный `each`, который без блока сразу вызывает `yield`, нарушает протокол Enumerable и поднимает LocalJumpError.
Отмечать в обзоре кода операции, которые разрывают ленивость, и измерять число прочитанных элементов на характерном источнике. Это изменение устраняет проблему: самодельный `each`, который без блока сразу вызывает `yield`, нарушает протокол Enumerable и поднимает LocalJumpError.
Не выполнять пробный полный обход одноразового источника; собирать нужные метрики за один проход либо буферизовать осознанно. Это изменение устраняет проблему: самодельный `each`, который без блока сразу вызывает `yield`, нарушает протокол Enumerable и поднимает LocalJumpError.
Следовать протоколу `return enum_for(__method__) unless block_given?` и тестировать возврат самого объекта при обходе с блоком. Это изменение устраняет проблему: код, который сначала делает `count`, а затем `map` по одноразовому источнику, может второй раз получить пустой поток.
Вопрос 18 из 25
Какое исправление уменьшает риск, не скрывая исходное поведение «Ленивость»? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Ruby Ruby — Ленивость Копировать
# Выберите изменение, которое исправляет причину.
seen = 0
result = (1..).lazy
.map { |n| seen += 1; n * 2 }
.select { |n| n > 4 }
.first(2)
p [result, seen]
Отмечать в обзоре кода операции, которые разрывают ленивость, и измерять число прочитанных элементов на характерном источнике. Такая правка нужна из-за риска: генератор без условия завершения безопасен только вместе с ленивым ограничителем; прямой `to_a` на нём никогда не закончится.
Не выполнять пробный полный обход одноразового источника; собирать нужные метрики за один проход либо буферизовать осознанно. Такая правка нужна из-за риска: вставка `force`, `to_a`, `sort` или `group_by` материализует поток и может превратить ограниченную задачу в обработку всего источника.
Отмечать в обзоре кода операции, которые разрывают ленивость, и измерять число прочитанных элементов на характерном источнике. Такая правка нужна из-за риска: один Enumerator хранит состояние обхода; совместное использование разными потребителями приводит к пропускам и зависимости от порядка вызовов.
Следовать протоколу `return enum_for(__method__) unless block_given?` и тестировать возврат самого объекта при обходе с блоком. Такая правка нужна из-за риска: вставка `force`, `to_a`, `sort` или `group_by` материализует поток и может превратить ограниченную задачу в обработку всего источника.
Отмечать в обзоре кода операции, которые разрывают ленивость, и измерять число прочитанных элементов на характерном источнике. Такая правка нужна из-за риска: вставка `force`, `to_a`, `sort` или `group_by` материализует поток и может превратить ограниченную задачу в обработку всего источника.
Вопрос 19 из 25
Какое действие добавляет недостающую гарантию в блоке «Собственный итератор»? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Ruby Ruby — Собственный итератор Копировать
# Выберите изменение, которое исправляет причину.
squares = Enumerator.new do |y|
1.upto(3) { |n| y << n * n }
end
p squares.to_a
Явно документировать конечность источника и предоставлять ограничение по количеству, времени или сигналу отмены для открытого потока. Решение адресует следующий дефект: генератор без условия завершения безопасен только вместе с ленивым ограничителем; прямой `to_a` на нём никогда не закончится.
Явно документировать конечность источника и предоставлять ограничение по количеству, времени или сигналу отмены для открытого потока. Решение адресует следующий дефект: самодельный `each`, который без блока сразу вызывает `yield`, нарушает протокол Enumerable и поднимает LocalJumpError.
Отмечать в обзоре кода операции, которые разрывают ленивость, и измерять число прочитанных элементов на характерном источнике. Решение адресует следующий дефект: генератор без условия завершения безопасен только вместе с ленивым ограничителем; прямой `to_a` на нём никогда не закончится.
Явно документировать конечность источника и предоставлять ограничение по количеству, времени или сигналу отмены для открытого потока. Решение адресует следующий дефект: код, который сначала делает `count`, а затем `map` по одноразовому источнику, может второй раз получить пустой поток.
Следовать протоколу `return enum_for(__method__) unless block_given?` и тестировать возврат самого объекта при обходе с блоком. Решение адресует следующий дефект: генератор без условия завершения безопасен только вместе с ленивым ограничителем; прямой `to_a` на нём никогда не закончится.
Вопрос 20 из 25
Какое исправление уменьшает риск, не скрывая исходное поведение «Пограничные случаи»? В правильном ответе вторая часть действительно объясняет или проверяет первую.
Не выполнять пробный полный обход одноразового источника; собирать нужные метрики за один проход либо буферизовать осознанно. Именно эта мера закрывает риск: самодельный `each`, который без блока сразу вызывает `yield`, нарушает протокол Enumerable и поднимает LocalJumpError.
Не выполнять пробный полный обход одноразового источника; собирать нужные метрики за один проход либо буферизовать осознанно. Именно эта мера закрывает риск: генератор без условия завершения безопасен только вместе с ленивым ограничителем; прямой `to_a` на нём никогда не закончится.
Следовать протоколу `return enum_for(__method__) unless block_given?` и тестировать возврат самого объекта при обходе с блоком. Именно эта мера закрывает риск: код, который сначала делает `count`, а затем `map` по одноразовому источнику, может второй раз получить пустой поток.
Отмечать в обзоре кода операции, которые разрывают ленивость, и измерять число прочитанных элементов на характерном источнике. Именно эта мера закрывает риск: код, который сначала делает `count`, а затем `map` по одноразовому источнику, может второй раз получить пустой поток.
Не выполнять пробный полный обход одноразового источника; собирать нужные метрики за один проход либо буферизовать осознанно. Именно эта мера закрывает риск: код, который сначала делает `count`, а затем `map` по одноразовому источнику, может второй раз получить пустой поток.
Вопрос 23 из 25
Какую границу контракта «Ленивость» нужно закрепить отдельным тестом? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Проверить побочный эффект в ленивом блоке: до появления потребителя он вообще не выполняется. Проверка относится к изменению: не выполнять пробный полный обход одноразового источника; собирать нужные метрики за один проход либо буферизовать осознанно.
Проверить побочный эффект в ленивом блоке: до появления потребителя он вообще не выполняется. Проверка относится к изменению: следовать протоколу `return enum_for(__method__) unless block_given?` и тестировать возврат самого объекта при обходе с блоком.
Проверить, реализует ли источник `rewind` фактически, а не только отвечает на метод через обёртку. Проверка относится к изменению: отмечать в обзоре кода операции, которые разрывают ленивость, и измерять число прочитанных элементов на характерном источнике.
Проверить побочный эффект в ленивом блоке: до появления потребителя он вообще не выполняется. Проверка относится к изменению: отмечать в обзоре кода операции, которые разрывают ленивость, и измерять число прочитанных элементов на характерном источнике.
Проверить блок, который прерывает обход через break: значение break станет результатом вызова each. Проверка относится к изменению: отмечать в обзоре кода операции, которые разрывают ленивость, и измерять число прочитанных элементов на характерном источнике.
Вопрос 24 из 25
Какой случай покажет, что исправление «Собственный итератор» не держится на удачном входе? Выберите связку, в которой верны и основной вывод, и его обоснование.
Проверить исключение внутри генератора: оно возникает у потребителя в момент запроса соответствующего элемента. Сценарий подтверждает надёжность решения: следовать протоколу `return enum_for(__method__) unless block_given?` и тестировать возврат самого объекта при обходе с блоком.
Проверить, реализует ли источник `rewind` фактически, а не только отвечает на метод через обёртку. Сценарий подтверждает надёжность решения: явно документировать конечность источника и предоставлять ограничение по количеству, времени или сигналу отмены для открытого потока.
Проверить исключение внутри генератора: оно возникает у потребителя в момент запроса соответствующего элемента. Сценарий подтверждает надёжность решения: отмечать в обзоре кода операции, которые разрывают ленивость, и измерять число прочитанных элементов на характерном источнике.
Проверить исключение внутри генератора: оно возникает у потребителя в момент запроса соответствующего элемента. Сценарий подтверждает надёжность решения: явно документировать конечность источника и предоставлять ограничение по количеству, времени или сигналу отмены для открытого потока.
Проверить блок, который прерывает обход через break: значение break станет результатом вызова each. Сценарий подтверждает надёжность решения: явно документировать конечность источника и предоставлять ограничение по количеству, времени или сигналу отмены для открытого потока.
Вопрос 25 из 25
Какой случай покажет, что исправление «Пограничные случаи» не держится на удачном входе? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Проверить побочный эффект в ленивом блоке: до появления потребителя он вообще не выполняется. На этой границе проверяется мера: не выполнять пробный полный обход одноразового источника; собирать нужные метрики за один проход либо буферизовать осознанно.
Проверить блок, который прерывает обход через break: значение break станет результатом вызова each. На этой границе проверяется мера: не выполнять пробный полный обход одноразового источника; собирать нужные метрики за один проход либо буферизовать осознанно.
Проверить, реализует ли источник `rewind` фактически, а не только отвечает на метод через обёртку. На этой границе проверяется мера: отмечать в обзоре кода операции, которые разрывают ленивость, и измерять число прочитанных элементов на характерном источнике.
Проверить, реализует ли источник `rewind` фактически, а не только отвечает на метод через обёртку. На этой границе проверяется мера: не выполнять пробный полный обход одноразового источника; собирать нужные метрики за один проход либо буферизовать осознанно.
Проверить, реализует ли источник `rewind` фактически, а не только отвечает на метод через обёртку. На этой границе проверяется мера: следовать протоколу `return enum_for(__method__) unless block_given?` и тестировать возврат самого объекта при обходе с блоком.