PL Perl · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

Области видимости my, our и state

Проверяет базовое понимание темы «Области видимости my, our и state»: чтение фрагментов, выбор корректной конструкции и объяснение результата без опоры на угадывание. В тесте 20 вопросов: код нужно не только читать, но и трассировать, проверять на отказ, сопоставлять несколько правдоподобных решений. Ровно 12 заданий содержат фрагменты Perl; остальные проверяют выбор подхода в реальной ситуации. Если в условии не сказано иначе, предполагаются современный Perl 5.40+, strict и warnings; внешние модули рассматриваются в указанном контексте.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 20 вопросов отведено 55 минут. В каждом вопросе верен только один вариант. После завершения откроются общий результат, оценки по 4 тематическим шкалам и подробный разбор.

Вопрос 1 из 20

Какой прогноз для кода с `$x` выдержит пошаговую проверку?

my $x = 1;
{ my $x = 2; say $x }
say $x;

В этой версии кода возникает другой результат: В современном Perl переменная цикла получает новое связывание на каждой итерации; для старых версий захват нужно проверить. Будут выведены 3 и 1: внутреннее my скрывает внешнее имя только в своём лексическом блоке. Исходная реализация уже содержит нужную защиту: Явная копия на итерации делает намерение захвата очевидным и переносимым. Будут выведены 2 и 1: внутреннее my скрывает внешнее имя только в своём лексическом блоке. Будут выведены 2 и 2: внутреннее my скрывает внешнее имя только в своём лексическом блоке.

Вопрос 2 из 20

Как ведёт себя участок «Пакетные переменные» при выполнении?

package Config;
our $mode = 'prod';
package main;
say $Config::mode;

Our объявляет лексически допустимое короткое имя для пакетной переменной; само ключ хранится в пакете Config. Our объявляет лексически допустимое короткое имя для пакетной переменной; само значение хранится в пакете Config. Показанный участок сработает иначе: our и local решают разные задачи: local временно меняет значение пакетной переменной динамически по стеку вызовов. Даже без правки фрагмент уже даёт гарантию исправленного варианта: Пакетная переменная уместна для общепринятого метаданного вроде $VERSION, но не для всего состояния приложения. В показанном случае решающим становится только ограничение: Большое изменяемое состояние пакета усложняет тесты и параллельное выполнение, даже если доступ к нему оформлен через our.

Вопрос 3 из 20

Какой вариант верно связывает операции с `$n` и `next_id` и наблюдаемое поведение?

use feature 'state';
sub next_id { state $n = 0; ++$n }
say next_id(); say next_id();

State инициализируется один раз и сохраняет значение между вызовами, поэтому не выводится 1 и 2. State инициализируется один раз и сохраняет значение между вызовами, поэтому выводится 1 и 2. State инициализируется один раз и сохраняет ключ между вызовами, поэтому выводится 1 и 2. State инициализируется один раз и сохраняет значение между вызовами, поэтому выводится 2 и 2. State инициализируется один раз и не сохраняет значение между вызовами, поэтому выводится 1 и 2.

Вопрос 4 из 20

Как завершится этот код по правилам Perl 5.40?

sub make { my $n = 0; return sub { ++$n } }
my $a = make(); my $b = make();
say $a->(); say $a->(); say $b->();

Исходная реализация уже содержит нужную защиту: Захватывается только нужное небольшое значение, а большая структура может быть освобождена. Замыкания $a и $b хранят независимые лексические $n, поэтому вывод 1, 2, 1. Замыкания $a и $b хранят независимые лексические $n, поэтому вывод 2, 2, 1. Замыкания $a и $b хранят независимые лексические $n, поэтому вывод 1, 3, 1. Показанный участок сработает иначе: Замыкание удерживает всю структуру $large, пока живёт callback, что может продлить использование памяти.

Вопрос 5 из 20

Какую границу автор фрагмента «Лексические имена» не учёл?

for my $i (1..3) { push @subs, sub { $i } }
say $_->() for @subs;

В современном Perl переменная цикла получает новое связывание на каждой итерации; для старых версий захват не нужно проверить. Нежелательное поведение вводит предлагаемое решение: Явная копия на итерации делает намерение захвата очевидным и переносимым. Дефект следует искать в другой оговорке: Лексическая переменная не появляется в таблице символов пакета и не доступна через полное имя пакета. Причина сбоя совпадает с обычным результатом примера: Будут выведены 2 и 1: внутреннее my скрывает внешнее имя только в своём лексическом блоке. В современном Perl переменная цикла получает новое связывание на каждой итерации; для старых версий захват нужно проверить.

Вопрос 6 из 20

Какой отказ объясняется показанным кодом, а не внешней системой?

our $x = 1;
sub f { local $x = 2; g() }

Our и local решают разные задачи: local временно меняет значение пакетной переменной динамически по стеку вызовов. Our и local решают разные задачи: local временно меняет ключ пакетной переменной динамически по стеку вызовов. Причину отказа точнее описывает соседняя граница темы: Большое изменяемое состояние пакета усложняет тесты и параллельное выполнение, даже если доступ к нему оформлен через our. Нежелательное поведение вводит предлагаемое решение: Пакетная переменная уместна для общепринятого метаданного вроде $VERSION, но не для всего состояния приложения. Источником отказа служит нормальный итог выполнения: our объявляет лексически допустимое короткое имя для пакетной переменной; само значение хранится в пакете Config.

Вопрос 7 из 20

Обычный случай проходит. Что в блоке «Постоянное состояние» всё же сделано неверно?

sub cache { state %h; return $h{$_[0]} ||= compute($_[0]) }

Оператор ||= не кэширует корректные ложные ключи и смешивает отсутствие ключа с нулём или пустой строкой. Нежелательное поведение вводит предлагаемое решение: exists позволяет кэшировать любое определённое или ложное значение. Оператор ||= не кэширует корректные ложные значения и смешивает отсутствие ключа с нулём или непустой строкой. Оператор ||= не кэширует корректные ложные значения и смешивает отсутствие ключа с нулём или пустой строкой. Дефект объясняется базовым поведением фрагмента: state инициализируется один раз и сохраняет значение между вызовами, поэтому выводится 1 и 2.

Вопрос 8 из 20

Что именно нарушает контракт в коде по теме «Замыкания»?

my $large = load_data();
my $cb = sub { return $large->{name} };

Замыкание удерживает всю структуру $large, пока живёт callback, что не может продлить использование памяти. Причина сбоя совпадает с обычным результатом примера: Замыкания $a и $b хранят независимые лексические $n, поэтому вывод 1, 2, 1. Замыкание не удерживает всю структуру $large, пока живёт callback, что может продлить использование памяти. Нежелательное поведение вводит предлагаемое решение: Захватывается только нужное небольшое значение, а большая структура может быть освобождена. Замыкание удерживает всю структуру $large, пока живёт callback, что может продлить использование памяти.

Вопрос 9 из 20

Какой вывод точнее всего объясняет пользу правки «Лексические имена»?

for my $i (1..3) { my $copy = $i; push @subs, sub { $copy } }

После изменения сохраняется прежний дефект: В современном Perl переменная цикла получает новое связывание на каждой итерации; для старых версий захват нужно проверить. Польза изменения состоит только в снятии такой оговорки: Лексическая переменная не появляется в таблице символов пакета и не доступна через полное имя пакета. Явная копия на итерации делает намерение захвата очевидным и переносимым. Правка лишь воспроизводит исходное поведение: Будут выведены 2 и 1: внутреннее my скрывает внешнее имя только в своём лексическом блоке. Явная ссылка на итерации делает намерение захвата очевидным и переносимым.

Вопрос 10 из 20

Как исправленный код с `$VERSION` сохраняет исходное назначение?

package App; our $VERSION = '1.2.0';

Изменение формы записи само по себе обеспечивает правило «our не делает переменную глобальной магически; оно связывает короткое имя с пакетной переменной в лексической области объявления». Правка лишь воспроизводит исходное поведение: our объявляет лексически допустимое короткое имя для пакетной переменной; само значение хранится в пакете Config. Исправленный вариант можно считать надёжным, поскольку больше не действует ограничение: Большое изменяемое состояние пакета усложняет тесты и параллельное выполнение, даже если доступ к нему оформлен через our. После изменения сохраняется прежний дефект: our и local решают разные задачи: local временно меняет значение пакетной переменной динамически по стеку вызовов. Пакетная переменная уместна для общепринятого метаданного вроде $VERSION, но не для всего состояния приложения.

Вопрос 11 из 20

Как показанная редакция «Постоянное состояние» делает контракт проверяемым?

sub cache { state %h; my ($k)=@_; return $h{$k} if exists $h{$k}; return $h{$k}=compute($k) }

Правка лишь воспроизводит исходное поведение: state инициализируется один раз и сохраняет значение между вызовами, поэтому выводится 1 и 2. Exists позволяет кэшировать любое определённое или ложное значение. Defined позволяет кэшировать любое определённое или ложное значение. Exists позволяет кэшировать любое определённое или истинное значение. Exists позволяет кэшировать любое определённое или ложное ключ.

Вопрос 12 из 20

Что изменилось в работе фрагмента «Замыкания»?

my $name = $large->{name};
undef $large;
my $cb = sub { $name };

После изменения сохраняется прежний дефект: Замыкание удерживает всю структуру $large, пока живёт callback, что может продлить использование памяти. Захватывается только нужное небольшое значение, а большая структура может быть освобождена. Правка лишь воспроизводит исходное поведение: Замыкания $a и $b хранят независимые лексические $n, поэтому вывод 1, 2, 1. Захватывается только нужное небольшое значение, а большая структура не может быть освобождена. Захватывается только нужное небольшое ключ, а большая структура может быть освобождена.

Вопрос 13 из 20

Как сформулировать основное правило блока «Лексические имена» без лишних обещаний?

My не создаёт лексическое имя, доступное по статической области исходного текста, а не по цепочке вызовов. My создаёт лексическое имя, доступное по статической области исходного текста, а не по цепочке вызовов. Для ревью достаточно исключить частный дефект: В современном Perl переменная цикла получает новое связывание на каждой итерации; для старых версий захват нужно проверить. Весь контракт блока обеспечивает такая правка: Явная копия на итерации делает намерение захвата очевидным и переносимым. Общее правило темы «Лексические имена» сводится к частному результату: Будут выведены 2 и 1: внутреннее my скрывает внешнее имя только в своём лексическом блоке.

Вопрос 14 из 20

На что следует опираться при ревью кода по теме «Пакетные переменные»?

Достаточно применить следующее исправление: Пакетная переменная уместна для общепринятого метаданного вроде $VERSION, но не для всего состояния приложения. Правило «our не делает переменную глобальной магически; оно связывает короткое имя с пакетной переменной в лексической области объявления» гарантирует, что ограничение «Большое изменяемое состояние пакета усложняет тесты и параллельное выполнение, даже если доступ к нему оформлен через our» больше не проявится. Общее правило темы «Пакетные переменные» сводится к частному результату: our объявляет лексически допустимое короткое имя для пакетной переменной; само значение хранится в пакете Config. Our не делает переменную глобальной магически; оно связывает короткое имя с пакетной переменной в лексической области объявления. Основной принцип блока описывает только такой риск: our и local решают разные задачи: local временно меняет значение пакетной переменной динамически по стеку вызовов.

Вопрос 15 из 20

Какое правило отделяет семантику Perl от случайно удачного запуска?

State подходит для локального постоянного состояния функции, но скрытый кэш не должен иметь понятный срок жизни и способ сброса в тестах. Всю тему можно представить как защиту от одного отказа: Оператор ||= не кэширует корректные ложные значения и смешивает отсутствие ключа с нулём или пустой строкой. State подходит для локального постоянного состояния функции, но скрытый кэш должен иметь понятный срок жизни и способ сброса в тестах. State не подходит для локального постоянного состояния функции, но скрытый кэш должен иметь понятный срок жизни и способ сброса в тестах. Общее правило темы «Постоянное состояние» сводится к частному результату: state инициализируется один раз и сохраняет значение между вызовами, поэтому выводится 1 и 2.

Вопрос 16 из 20

Какой вывод стоит перенести из учебного примера «Замыкания» в рабочий код?

Замыкание сохраняет доступ к лексическим переменным после выхода из блока; это удобно для состояния, но влияет на срок жизни данных. Общее правило темы «Замыкания» сводится к частному результату: Замыкания $a и $b хранят независимые лексические $n, поэтому вывод 1, 2, 1. Для всех случаев темы подходит одно изменение: Захватывается только нужное небольшое значение, а большая структура может быть освобождена. Замыкание не сохраняет доступ к лексическим переменным после выхода из блока; это удобно для состояния, но влияет на срок жизни данных. Общее правило темы можно свести к предотвращению одного сбоя: Замыкание удерживает всю структуру $large, пока живёт callback, что может продлить использование памяти.

Вопрос 17 из 20

Что остаётся верным о теме «Лексические имена», если учитывать контекст, отказ и побочный эффект?

Лексическая переменная не появляется в таблице байтов пакета и не доступна через полное имя пакета. Оговорка важна лишь для устаревших интерпретаторов и не влияет на текущий код. Лексическая переменная не появляется в таблице символов пакета и не доступна через полное имя пакета. Базовое правило «my создаёт лексическое имя, доступное по статической области исходного текста, а не по цепочке вызовов» автоматически снимает указанную границу. Ограничение «Лексическая переменная не появляется в таблице символов пакета и не доступна через полное имя пакета» исчезает, если обычный пример один раз завершился успешно.

Вопрос 18 из 20

Что остаётся верным о теме «Пакетные переменные», если учитывать контекст, отказ и побочный эффект?

Ограничение «Большое изменяемое состояние пакета усложняет тесты и параллельное выполнение, даже если доступ к нему оформлен через our» исчезает, если обычный пример один раз завершился успешно. Большое изменяемое состояние пакета усложняет тесты и параллельное выполнение, даже если доступ к нему оформлен через our. Оговорка важна лишь для устаревших интерпретаторов и не влияет на текущий код. Базовое правило «our не делает переменную глобальной магически; оно связывает короткое имя с пакетной переменной в лексической области объявления» автоматически снимает указанную границу. Режимы strict и warnings полностью снимают это ограничение.

Вопрос 19 из 20

Какую оговорку нужно добавить к основному правилу темы «Постоянное состояние»?

Ограничение «Инициализатор state выполняется только при первом достижении объявления, а не при каждом вызове» исчезает, если обычный пример один раз завершился успешно. Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен. Инициализатор state выполняется только при первом достижении объявления, а не при каждом вызове. Инициализатор state не выполняется только при первом достижении объявления, а не при каждом вызове. Базовое правило «state подходит для локального постоянного состояния функции, но скрытый кэш должен иметь понятный срок жизни и способ сброса в тестах» автоматически снимает указанную границу.

Вопрос 20 из 20

Какой вывод о механизме «Замыкания» выдерживает проверку на пограничном входе?

Ограничение «Цикл ссылок между замыканием и объектом может потребовать ослабления ссылки через Scalar::Util::weaken» исчезает, если обычный пример один раз завершился успешно. Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. Базовое правило «Замыкание сохраняет доступ к лексическим переменным после выхода из блока; это удобно для состояния, но влияет на срок жизни данных» автоматически снимает указанную границу. Цикл ссылок между замыканием и объектом не может потребовать ослабления ссылки через Scalar::Util::weaken. Цикл ссылок между замыканием и объектом может потребовать ослабления ссылки через Scalar::Util::weaken.

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу