Пакеты и модули — бесплатный тест онлайн

Вопрос 1 из 25

Как точнее всего описать действие фрагмента с `$MODE`?

package App::Config;
our $MODE = 'prod';
sub mode { $MODE }
1;

Package меняет текущее пространство имён; завершающее истинное значение позволяет require считать загрузку успешной. Показанный участок сработает иначе: Если последним вычисленным значением окажется ложное, require сообщит, что модуль не вернул истинное значение. Дополнительное изменение не требуется, поскольку код уже обеспечивает следующее: Модуль явно включает проверки и гарантированно завершается истинным значением. Package меняет текущее пространство имён; завершающее ложное значение позволяет require считать загрузку успешной. Package меняет текущее пространство имён; завершающее истинное ключ позволяет require считать загрузку успешной.

Вопрос 2 из 25

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

use My::Tool 2.10 qw(run);

В этой версии кода возникает другой результат: use всё равно обрабатывается при компиляции, поэтому условие времени выполнения не делает зависимость действительно необязательной. Use выполняется на этапе компиляции, проверяет версию и вызывает import с указанным списком. Use не выполняется на этапе компиляции, проверяет версию и вызывает import с указанным списком. Use выполняется во время выполнения, проверяет версию и вызывает import с указанным списком. Use выполняется на этапе компиляции, не проверяет версию и вызывает import с указанным списком.

Вопрос 3 из 25

Не запуская фрагмент «Экспорт», выберите точное описание его работы.

package Tools;
use Exporter 'import';
our @EXPORT_OK = qw(clean);
sub clean {
    my ($text) = @_;
    $text =~ s/\s+/ /g;
    return $text;
}
1;

Показанный участок сработает иначе: Безусловный экспорт общих имён загрязняет пространство вызывающего кода и создаёт конфликты со встроенными функциями. Единственное существенное правило этого запуска — следующая оговорка: Экспорт копирует имя функции в таблицу символов вызывающего пакета; он не создаёт отдельную реализацию. Функция import экспортируется только по явному запросу вызывающего модуля. Функция clean экспортируется только по явному запросу вызывающего модуля. Показанная версия изначально работает как исправленная: Экспорт остаётся добровольным, а тег группирует согласованный набор функций.

Вопрос 4 из 25

Какое утверждение точно описывает поведение фрагмента «Пространства имён» с `id`?

package A; sub id {'A'}
package B; sub id {'B'}
package main; say A::id();

Непосредственным итогом выполнения будет: Неквалифицированный helper внутри App ищется как App::helper, а не автоматически в main. В показанном коде «Пространства имён» проявляется другой эффект: неквалифицированный helper внутри App ищется как App::helper, а не автоматически в main. Для результата здесь достаточно учесть лишь такое условие: Лексические my-переменные не доступны через App::$name; пакетные и лексические пространства устроены по-разному. Текущее поведение совпадает с результатом предлагаемой правки: Явная квалификация показывает намеренную зависимость от другого пакета, хотя лучше внедрить её через интерфейс. Полностью квалифицированное имя однозначно вызывает функцию пакета A.

Вопрос 5 из 25

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

BEGIN { require Feature; Feature->import }
say Feature::enabled();

BEGIN не выполняется во время компиляции, поэтому модуль доступен последующим компилируемым конструкциям. BEGIN выполняется во время выполнения, поэтому модуль доступен последующим компилируемым конструкциям. Главным результатом фрагмента станет следующее: Загрузка пути из непроверенного ввода позволяет выполнить произвольный Perl-код. BEGIN выполняется во время компиляции, поэтому модуль доступен последующим компилируемым конструкциям. Исходная реализация уже содержит нужную защиту: Выбор ограничен закрытым списком известных модулей и не принимает произвольный путь.

Вопрос 6 из 25

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

package App::Config;
sub mode { 'prod' }
# файл заканчивается здесь

Если последним вычисленным значением окажется ложное, require сообщит, что модуль не вернул истинное значение. Если последним вычисленным значением окажется истинное, require сообщит, что модуль не вернул истинное значение. Если последним вычисленным значением окажется ложное, require сообщит, что модуль не вернул истинное ключ. Дефект объясняется базовым поведением фрагмента: package меняет текущее пространство имён; завершающее истинное значение позволяет require считать загрузку успешной. Если последним вычисленным значением окажется ложное, require сообщит, что модуль не вернул ложное значение.

Вопрос 7 из 25

Какой диагноз точнее всего относится к участку с `$need`?

if ($need) { use Optional::Tool; }

Use всё равно обрабатывается при компиляции, поэтому условие времени выполнения не делает зависимость действительно необязательной. Дефект объясняется базовым поведением фрагмента: use выполняется на этапе компиляции, проверяет версию и вызывает import с указанным списком. Нежелательное поведение вводит предлагаемое решение: require откладывает загрузку до выполнения; импорт при необходимости вызывается явно. Показанный код уже соблюдает правило «use подходит для обязательной зависимости и ранней ошибки, require — для контролируемой отложенной загрузки», поэтому отдельного дефекта нет. Показанный сбой объясняется не кодом, а таким пределом механизма: require кэширует загруженные файлы в %INC; повторный вызов обычно не перечитывает модуль.

Вопрос 8 из 25

Что нужно заметить при ревью фрагмента «Экспорт»?

our @EXPORT = qw(open close map);

Безусловный экспорт общих имён загрязняет пространство вызывающего кода и не создаёт конфликты со встроенными функциями. Основная проблема здесь — сам результат штатного случая: Функция clean экспортируется только по явному запросу вызывающего модуля. Риск появляется после применения рекомендуемой правки: Экспорт остаётся добровольным, а тег группирует согласованный набор функций. Безусловный экспорт общих имён загрязняет пространство вызывающего кода и создаёт конфликты со встроенными функциями. Главный риск этого участка задаёт другое ограничение механизма: Экспорт копирует имя функции в таблицу символов вызывающего пакета; он не создаёт отдельную реализацию.

Вопрос 9 из 25

Почему участок с `helper` ненадёжен на пограничном входе?

package App;
sub run { helper() }

package main;
sub helper { return 'ok' }

Неквалифицированный helper внутри App ищется как App::helper, а не автоматически в main. Сбой создаёт именно предложенное исправление: Явная квалификация показывает намеренную зависимость от другого пакета, хотя лучше внедрить её через интерфейс. Причину отказа точнее описывает соседняя граница темы: Лексические my-переменные не доступны через App::$name; пакетные и лексические пространства устроены по-разному. Дефект объясняется базовым поведением фрагмента: Полностью квалифицированное имя однозначно вызывает функцию пакета A. Показанный код уже соблюдает правило «Полные имена уменьшают неоднозначность, но чрезмерные прямые связи между пакетами ухудшают модульность», поэтому отдельного дефекта нет.

Вопрос 10 из 25

Какой риск показанного участка относится к теме «Пограничные случаи»?

my $file = $ARGV[0];
require $file;

Нежелательное поведение вводит предлагаемое решение: Выбор ограничен закрытым списком известных модулей и не принимает произвольный путь. Показанный код уже соблюдает правило «Динамическую загрузку ограничивают белым списком и обрабатывают ошибку отдельно от ошибок самого импортируемого модуля», поэтому отдельного дефекта нет. Риск возникает уже в обычном результате: BEGIN выполняется во время компиляции, поэтому модуль доступен последующим компилируемым конструкциям. Главный риск этого участка задаёт другое ограничение механизма: Строковый require и require Module::Name имеют разный синтаксис преобразования пути; eval STRING для загрузки не нужен. Загрузка пути из непроверенного ввода позволяет выполнить произвольный Perl-код.

Вопрос 11 из 25

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

package App::Config;
use strict; use warnings;
sub mode { 'prod' }
1;

Правка решает задачу тем, что устраняет следующую границу: package не создаёт объект и не импортирует функции; оно лишь задаёт пакет для последующих имён. Правка лишь воспроизводит исходное поведение: package меняет текущее пространство имён; завершающее истинное значение позволяет require считать загрузку успешной. Модуль неявно включает проверки и гарантированно завершается истинным значением. После изменения сохраняется прежний дефект: Если последним вычисленным значением окажется ложное, require сообщит, что модуль не вернул истинное значение. Модуль явно включает проверки и гарантированно завершается истинным значением.

Вопрос 12 из 25

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

if ($need) { require Optional::Tool; Optional::Tool->import('run'); }

После изменения сохраняется прежний дефект: use всё равно обрабатывается при компиляции, поэтому условие времени выполнения не делает зависимость действительно необязательной. Гарантию исправления даёт исчезновение ограничения: require кэширует загруженные файлы в %INC; повторный вызов обычно не перечитывает модуль. Require откладывает загрузку до выполнения; импорт при необходимости вызывается неявно. Require откладывает загрузку до выполнения; импорт при необходимости вызывается явно. Правка лишь воспроизводит исходное поведение: use выполняется на этапе компиляции, проверяет версию и вызывает import с указанным списком.

Вопрос 13 из 25

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

our @EXPORT_OK = qw(clean parse);
our %EXPORT_TAGS = (all => [@EXPORT_OK]);

После изменения сохраняется прежний дефект: Безусловный экспорт общих имён загрязняет пространство вызывающего кода и создаёт конфликты со встроенными функциями. Польза изменения состоит только в снятии такой оговорки: Экспорт копирует имя функции в таблицу символов вызывающего пакета; он не создаёт отдельную реализацию. Изменение формы записи само по себе обеспечивает правило «По умолчанию безопаснее ничего не экспортировать либо использовать @EXPORT_OK для явного импорта». Экспорт остаётся добровольным, а тег группирует согласованный набор функций. Правка лишь воспроизводит исходное поведение: Функция clean экспортируется только по явному запросу вызывающего модуля.

Вопрос 14 из 25

Как правка с `helper` меняет поведение на неудобном входе?

package App;
sub run { main::helper() }

Правка лишь воспроизводит исходное поведение: Полностью квалифицированное имя однозначно вызывает функцию пакета A. Изменение формы записи само по себе обеспечивает правило «Полные имена уменьшают неоднозначность, но чрезмерные прямые связи между пакетами ухудшают модульность». Польза изменения состоит только в снятии такой оговорки: Лексические my-переменные не доступны через App::$name; пакетные и лексические пространства устроены по-разному. Явная квалификация показывает намеренную зависимость от другого пакета, хотя лучше внедрить её через интерфейс. После изменения сохраняется прежний дефект: Неквалифицированный helper внутри App ищется как App::helper, а не автоматически в main.

Вопрос 15 из 25

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

my %allowed = (json => 'App/JSON.pm');
require $allowed{$kind} // die 'unsupported';

Правка лишь воспроизводит исходное поведение: BEGIN выполняется во время компиляции, поэтому модуль доступен последующим компилируемым конструкциям. После изменения сохраняется прежний дефект: Загрузка пути из непроверенного ввода позволяет выполнить произвольный Perl-код. Изменение формы записи само по себе обеспечивает правило «Динамическую загрузку ограничивают белым списком и обрабатывают ошибку отдельно от ошибок самого импортируемого модуля». Выбор ограничен закрытым списком известных модулей и не принимает произвольный путь. Гарантию исправления даёт исчезновение ограничения: Строковый require и require Module::Name имеют разный синтаксис преобразования пути; eval STRING для загрузки не нужен.

Вопрос 16 из 25

Какой принцип объясняет три кодовых примера блока «Объявление и пространство пакета»?

Общее правило темы «Объявление и пространство пакета» сводится к частному результату: package меняет текущее пространство имён; завершающее истинное значение позволяет require считать загрузку успешной. Один файл не может объявлять несколько пакетов, но путь модуля и основное пространство имён лучше согласовывать для понятной загрузки. Один файл может объявлять несколько пакетов, но путь модуля и основное пространство имён лучше согласовывать для понятной загрузки. Основной принцип блока описывает только такой риск: Если последним вычисленным значением окажется ложное, require сообщит, что модуль не вернул истинное значение. Общее правило исчерпывается единственной правкой: Модуль явно включает проверки и гарантированно завершается истинным значением.

Вопрос 17 из 25

Какое правило связывает пять заданий блока «use и require»?

Для ревью достаточно исключить частный дефект: use всё равно обрабатывается при компиляции, поэтому условие времени выполнения не делает зависимость действительно необязательной. Общее правило темы «use и require» сводится к частному результату: use выполняется на этапе компиляции, проверяет версию и вызывает import с указанным списком. Один приём полностью закрывает тему: require откладывает загрузку до выполнения; импорт при необходимости вызывается явно. Use не подходит для обязательной зависимости и ранней ошибки, require — для контролируемой отложенной загрузки. Use подходит для обязательной зависимости и ранней ошибки, require — для контролируемой отложенной загрузки.

Вопрос 18 из 25

Что точнее всего описывает контракт механизма «Экспорт»?

По умолчанию безопаснее ничего не экспортировать либо использовать @EXPORT_OK для явного импорта. Общее правило темы «Экспорт» сводится к частному результату: Функция clean экспортируется только по явному запросу вызывающего модуля. Правило «По умолчанию безопаснее ничего не экспортировать либо использовать @EXPORT_OK для явного импорта» гарантирует, что ограничение «Экспорт копирует имя функции в таблицу символов вызывающего пакета; он не создаёт отдельную реализацию» больше не проявится. Общее правило темы можно свести к предотвращению одного сбоя: Безусловный экспорт общих имён загрязняет пространство вызывающего кода и создаёт конфликты со встроенными функциями. Общее правило исчерпывается единственной правкой: Экспорт остаётся добровольным, а тег группирует согласованный набор функций.

Вопрос 19 из 25

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

Полные имена уменьшают неоднозначность, но чрезмерные прямые связи между пакетами ухудшают модульность. Правило «Полные имена уменьшают неоднозначность, но чрезмерные прямые связи между пакетами ухудшают модульность» гарантирует, что ограничение «Лексические my-переменные не доступны через App::$name; пакетные и лексические пространства устроены по-разному» больше не проявится. Общее правило темы «Пространства имён» сводится к частному результату: Полностью квалифицированное имя однозначно вызывает функцию пакета A. Весь контракт блока обеспечивает такая правка: Явная квалификация показывает намеренную зависимость от другого пакета, хотя лучше внедрить её через интерфейс. Всю тему можно представить как защиту от одного отказа: Неквалифицированный helper внутри App ищется как App::helper, а не автоматически в main.

Вопрос 20 из 25

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

Один приём полностью закрывает тему: Выбор ограничен закрытым списком известных модулей и не принимает произвольный путь. Динамическую загрузку ограничивают белым списком и обрабатывают успех отдельно от ошибок самого импортируемого модуля. Основной принцип блока описывает только такой риск: Загрузка пути из непроверенного ввода позволяет выполнить произвольный Perl-код. Динамическую загрузку ограничивают белым списком и обрабатывают ошибку отдельно от ошибок самого импортируемого модуля. Общее правило темы «Пограничные случаи» сводится к частному результату: BEGIN выполняется во время компиляции, поэтому модуль доступен последующим компилируемым конструкциям.

Вопрос 21 из 25

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

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

Вопрос 22 из 25

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

После включения strict и warnings указанная граница больше не может проявиться. Базовое правило «use подходит для обязательной зависимости и ранней ошибки, require — для контролируемой отложенной загрузки» автоматически снимает указанную границу. Ограничение «require кэширует загруженные файлы в %INC; повторный вызов обычно не перечитывает модуль» исчезает, если обычный пример один раз завершился успешно. Require кэширует загруженные файлы в %INC; повторный вызов обычно не перечитывает модуль. В актуальной версии Perl эта граница больше не действует.

Вопрос 23 из 25

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

Ограничение «Экспорт копирует имя функции в таблицу символов вызывающего пакета; он не создаёт отдельную реализацию» исчезает, если обычный пример один раз завершился успешно. Экспорт копирует имя функции в таблицу символов вызывающего пакета; он создаёт отдельную реализацию. Базовое правило «По умолчанию безопаснее ничего не экспортировать либо использовать @EXPORT_OK для явного импорта» автоматически снимает указанную границу. Экспорт копирует имя функции в таблицу байтов вызывающего пакета; он не создаёт отдельную реализацию. Экспорт копирует имя функции в таблицу символов вызывающего пакета; он не создаёт отдельную реализацию.

Вопрос 24 из 25

Что важно отдельно проверить при переносе приёма «Пространства имён» в рабочий код?

Лексические my-переменные не доступны через App::$name; пакетные и лексические пространства устроены по-разному. Режимы strict и warnings полностью снимают это ограничение. Базовое правило «Полные имена уменьшают неоднозначность, но чрезмерные прямые связи между пакетами ухудшают модульность» автоматически снимает указанную границу. В актуальной версии Perl эта граница больше не действует. Ограничение «Лексические my-переменные не доступны через App::$name; пакетные и лексические пространства устроены по-разному» исчезает, если обычный пример один раз завершился успешно.

Вопрос 25 из 25

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

Достаточно включить strict и warnings, чтобы пограничный случай стал невозможен. Базовое правило «Динамическую загрузку ограничивают белым списком и обрабатывают ошибку отдельно от ошибок самого импортируемого модуля» автоматически снимает указанную границу. Строковый require и require Module::Name имеют разный синтаксис преобразования пути; eval STRING для загрузки не нужен. Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен. Ограничение «Строковый require и require Module::Name имеют разный синтаксис преобразования пути; eval STRING для загрузки не нужен» исчезает, если обычный пример один раз завершился успешно.