Модули и пространства имён — бесплатный тест онлайн

Вопрос 1 из 20

Как нужно интерпретировать `module Metrics`, не добавляя к коду лишних гарантий?

\mathcal{N}(M_1)\cap\mathcal{N}(M_2)

module Metrics
export mean_score
mean_score(xs) = sum(xs) / length(xs)
_internal_scale(x) = 100x
end
@show Metrics.mean_score([1, 2, 3]) Metrics._internal_scale(2)

Совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`. `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта. `export` фиксирует обратную совместимость имени и запрещает менять его поведение в следующей основной версии. `using` и `import` различаются только тем, выводятся ли имена в подсказках редактора; расширять методы можно одинаково. `export` описывает публичные имена для `using`, но не скрывает остальные и не гарантирует стабильность API сам по себе.

Вопрос 2 из 20

Какой тест точнее всего зафиксирует границу поведения `module Metrics`?

module Metrics
export mean_score
mean_score(xs) = sum(xs) / length(xs)
_internal_scale(x) = 100x
end
@show Metrics.mean_score([1, 2, 3]) Metrics._internal_scale(2)

Проверить на отдельном примере, что совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`. Проверить на отдельном примере, что `export` описывает публичные имена для `using`, но не скрывает остальные и не гарантирует стабильность API сам по себе. Проверить на отдельном примере, что `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта. Проверить на отдельном примере, что `export` фиксирует обратную совместимость имени и запрещает менять его поведение в следующей основной версии. Проверить на отдельном примере, что `using` и `import` различаются только тем, выводятся ли имена в подсказках редактора; расширять методы можно одинаково.

Вопрос 3 из 20

Что должно остаться истинным после рефакторинга участка с `module Metrics`?

module Metrics
export mean_score
mean_score(xs) = sum(xs) / length(xs)
_internal_scale(x) = 100x
end
@show Metrics.mean_score([1, 2, 3]) Metrics._internal_scale(2)

Сохранить в реализации правило: `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта. Сохранить в реализации правило: `export` описывает публичные имена для `using`, но не скрывает остальные и не гарантирует стабильность API сам по себе. Сохранить в реализации правило: `using` и `import` различаются только тем, выводятся ли имена в подсказках редактора; расширять методы можно одинаково. Сохранить в реализации правило: `export` фиксирует обратную совместимость имени и запрещает менять его поведение в следующей основной версии. Сохранить в реализации правило: Совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`.

Вопрос 4 из 20

Как проверить, что новая реализация `module Metrics` не изменила обещанное пользователю поведение?

\mathcal{N}(M_1)\cap\mathcal{N}(M_2)

Приёмка должна подтвердить, что `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта. Приёмка должна подтвердить, что `using` и `import` различаются только тем, выводятся ли имена в подсказках редактора; расширять методы можно одинаково. Приёмка должна подтвердить, что `export` описывает публичные имена для `using`, но не скрывает остальные и не гарантирует стабильность API сам по себе. Приёмка должна подтвердить, что `export` фиксирует обратную совместимость имени и запрещает менять его поведение в следующей основной версии. Приёмка должна подтвердить, что совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`.

Вопрос 5 из 20

Какой тезис о `module Metrics` можно честно закрепить в справке?

Указать в документации: `export` описывает публичные имена для `using`, но не скрывает остальные и не гарантирует стабильность API сам по себе. Указать в документации: `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта. Указать в документации: Совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`. Указать в документации: `export` фиксирует обратную совместимость имени и запрещает менять его поведение в следующей основной версии. Указать в документации: `using` и `import` различаются только тем, выводятся ли имена в подсказках редактора; расширять методы можно одинаково.

Вопрос 6 из 20

Какой механизм Julia определяет поведение строки `f(x) = x + 1`?

\mathrm{using}\neq\mathrm{import}

module A
export f
f(x) = x + 1
g(x) = x - 1
end
using .A
@show f(3) A.g(3)

Метод чужой функции добавляют после `import` или через квалифицированное `M.f`; случайное создание новой локальной `f` не расширяет исходную таблицу методов. Неэкспортированное имя недоступно даже через квалифицированную запись `M.name`. `using M` делает доступными экспортированные имена, а `import M: f` разрешает добавлять методы к `f` без квалификации; эти операции не взаимозаменяемы. Совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`. `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта.

Вопрос 7 из 20

Что нужно подтвердить отдельным примером для `f(x) = x + 1`?

module A
export f
f(x) = x + 1
g(x) = x - 1
end
using .A
@show f(3) A.g(3)

Проверить на отдельном примере, что неэкспортированное имя недоступно даже через квалифицированную запись `M.name`. Проверить на отдельном примере, что метод чужой функции добавляют после `import` или через квалифицированное `M.f`; случайное создание новой локальной `f` не расширяет исходную таблицу методов. Проверить на отдельном примере, что совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`. Проверить на отдельном примере, что `using M` делает доступными экспортированные имена, а `import M: f` разрешает добавлять методы к `f` без квалификации; эти операции не взаимозаменяемы. Проверить на отдельном примере, что `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта.

Вопрос 8 из 20

Какое требование к `f(x) = x + 1` важнее удобной детали текущей реализации?

module A
export f
f(x) = x + 1
g(x) = x - 1
end
using .A
@show f(3) A.g(3)

Сохранить в реализации правило: Метод чужой функции добавляют после `import` или через квалифицированное `M.f`; случайное создание новой локальной `f` не расширяет исходную таблицу методов. Сохранить в реализации правило: Совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`. Сохранить в реализации правило: `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта. Сохранить в реализации правило: `using M` делает доступными экспортированные имена, а `import M: f` разрешает добавлять методы к `f` без квалификации; эти операции не взаимозаменяемы. Сохранить в реализации правило: Неэкспортированное имя недоступно даже через квалифицированную запись `M.name`.

Вопрос 9 из 20

Какой результат приёмочного теста подтвердит корректность участка с `f(x) = x + 1`?

\mathrm{using}\neq\mathrm{import}

Приёмка должна подтвердить, что неэкспортированное имя недоступно даже через квалифицированную запись `M.name`. Приёмка должна подтвердить, что `using M` делает доступными экспортированные имена, а `import M: f` разрешает добавлять методы к `f` без квалификации; эти операции не взаимозаменяемы. Приёмка должна подтвердить, что совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`. Приёмка должна подтвердить, что метод чужой функции добавляют после `import` или через квалифицированное `M.f`; случайное создание новой локальной `f` не расширяет исходную таблицу методов. Приёмка должна подтвердить, что `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта.

Вопрос 10 из 20

Как сформулировать границу механизма `f(x) = x + 1` без чрезмерного обещания?

Указать в документации: Совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`. Указать в документации: Метод чужой функции добавляют после `import` или через квалифицированное `M.f`; случайное создание новой локальной `f` не расширяет исходную таблицу методов. Указать в документации: `using M` делает доступными экспортированные имена, а `import M: f` разрешает добавлять методы к `f` без квалификации; эти операции не взаимозаменяемы. Указать в документации: `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта. Указать в документации: Неэкспортированное имя недоступно даже через квалифицированную запись `M.name`.

Вопрос 11 из 20

Какое утверждение точнее всего объясняет участок с `predict(m::Model, x) = m.w * x`?

E\subseteq\mathcal{N}(M)

module PublicAPI
export Model, predict
struct Model; w::Float64; end
predict(m::Model, x) = m.w * x
_debug(m) = m.w
end
@show names(PublicAPI)

`export` определяет имена, которые `using` вводит без квалификации; неэкспортированные имена по-прежнему доступны через имя модуля, а стабильность API требует отдельного обещания. Неэкспортированное имя нельзя вызвать даже через квалифицированную запись `Module.name`. Сам факт экспорта гарантирует обратную совместимость имени и запрещает менять его поведение в будущих версиях. После `export f` другой модуль может добавлять методы к `f` без `import` и без квалифицированной записи. `export` копирует значение в модуль пользователя, поэтому дальнейшее изменение исходной привязки не влияет на импортированное имя.

Вопрос 12 из 20

Какую проверку стоит добавить для участка с `predict(m::Model, x) = m.w * x`?

module PublicAPI
export Model, predict
struct Model; w::Float64; end
predict(m::Model, x) = m.w * x
_debug(m) = m.w
end
@show names(PublicAPI)

Проверить на отдельном примере, что `export` определяет имена, которые `using` вводит без квалификации; неэкспортированные имена по-прежнему доступны через имя модуля, а стабильность API требует отдельного обещания. Проверить на отдельном примере, что после `export f` другой модуль может добавлять методы к `f` без `import` и без квалифицированной записи. Проверить на отдельном примере, что сам факт экспорта гарантирует обратную совместимость имени и запрещает менять его поведение в будущих версиях. Проверить на отдельном примере, что `export` копирует значение в модуль пользователя, поэтому дальнейшее изменение исходной привязки не влияет на импортированное имя. Проверить на отдельном примере, что неэкспортированное имя нельзя вызвать даже через квалифицированную запись `Module.name`.

Вопрос 13 из 20

Что должно остаться истинным после рефакторинга участка с `predict(m::Model, x) = m.w * x`?

module PublicAPI
export Model, predict
struct Model; w::Float64; end
predict(m::Model, x) = m.w * x
_debug(m) = m.w
end
@show names(PublicAPI)

Сохранить в реализации правило: `export` определяет имена, которые `using` вводит без квалификации; неэкспортированные имена по-прежнему доступны через имя модуля, а стабильность API требует отдельного обещания. Сохранить в реализации правило: Сам факт экспорта гарантирует обратную совместимость имени и запрещает менять его поведение в будущих версиях. Сохранить в реализации правило: Неэкспортированное имя нельзя вызвать даже через квалифицированную запись `Module.name`. Сохранить в реализации правило: После `export f` другой модуль может добавлять методы к `f` без `import` и без квалифицированной записи. Сохранить в реализации правило: `export` копирует значение в модуль пользователя, поэтому дальнейшее изменение исходной привязки не влияет на импортированное имя.

Вопрос 14 из 20

При переносе кода с `predict(m::Model, x) = m.w * x` в библиотеку какой критерий нельзя заменять впечатлением «пример работает»?

E\subseteq\mathcal{N}(M)

Приёмка должна подтвердить, что `export` копирует значение в модуль пользователя, поэтому дальнейшее изменение исходной привязки не влияет на импортированное имя. Приёмка должна подтвердить, что сам факт экспорта гарантирует обратную совместимость имени и запрещает менять его поведение в будущих версиях. Приёмка должна подтвердить, что `export` определяет имена, которые `using` вводит без квалификации; неэкспортированные имена по-прежнему доступны через имя модуля, а стабильность API требует отдельного обещания. Приёмка должна подтвердить, что после `export f` другой модуль может добавлять методы к `f` без `import` и без квалифицированной записи. Приёмка должна подтвердить, что неэкспортированное имя нельзя вызвать даже через квалифицированную запись `Module.name`.

Вопрос 15 из 20

Что следует сообщить пользователю библиотеки о поведении `predict(m::Model, x) = m.w * x`?

Указать в документации: `export` копирует значение в модуль пользователя, поэтому дальнейшее изменение исходной привязки не влияет на импортированное имя. Указать в документации: Сам факт экспорта гарантирует обратную совместимость имени и запрещает менять его поведение в будущих версиях. Указать в документации: Неэкспортированное имя нельзя вызвать даже через квалифицированную запись `Module.name`. Указать в документации: `export` определяет имена, которые `using` вводит без квалификации; неэкспортированные имена по-прежнему доступны через имя модуля, а стабильность API требует отдельного обещания. Указать в документации: После `export f` другой модуль может добавлять методы к `f` без `import` и без квалифицированной записи.

Вопрос 16 из 20

Какое утверждение точнее всего объясняет участок с `render(x::AbstractVector) = join(x, ",")`?

M.f(x::T)

module CoreFns
export render
render(x::Number) = string(x)
end
import .CoreFns: render
render(x::AbstractVector) = join(x, ",")
@show render([1, 2, 3])

`using M` делает доступными экспортированные имена, а `import M: f` разрешает добавлять методы к `f` без квалификации; эти операции не взаимозаменяемы. `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта. Метод чужой функции добавляют после `import` или через квалифицированное `M.f`; случайное создание новой локальной `f` не расширяет исходную таблицу методов. Совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`. `export` описывает публичные имена для `using`, но не скрывает остальные и не гарантирует стабильность API сам по себе.

Вопрос 17 из 20

Какой контрольный тест лучше всего проверит правило, связанное с `render(x::AbstractVector) = join(x, ",")`?

module CoreFns
export render
render(x::Number) = string(x)
end
import .CoreFns: render
render(x::AbstractVector) = join(x, ",")
@show render([1, 2, 3])

Проверить на отдельном примере, что `using M` делает доступными экспортированные имена, а `import M: f` разрешает добавлять методы к `f` без квалификации; эти операции не взаимозаменяемы. Проверить на отдельном примере, что `export` описывает публичные имена для `using`, но не скрывает остальные и не гарантирует стабильность API сам по себе. Проверить на отдельном примере, что метод чужой функции добавляют после `import` или через квалифицированное `M.f`; случайное создание новой локальной `f` не расширяет исходную таблицу методов. Проверить на отдельном примере, что `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта. Проверить на отдельном примере, что совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`.

Вопрос 18 из 20

Какое решение устраняет риск вокруг `render(x::AbstractVector) = join(x, ",")`, не меняя поведение на допустимых данных?

module CoreFns
export render
render(x::Number) = string(x)
end
import .CoreFns: render
render(x::AbstractVector) = join(x, ",")
@show render([1, 2, 3])

Сохранить в реализации правило: Совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`. Сохранить в реализации правило: `export` описывает публичные имена для `using`, но не скрывает остальные и не гарантирует стабильность API сам по себе. Сохранить в реализации правило: `using M` делает доступными экспортированные имена, а `import M: f` разрешает добавлять методы к `f` без квалификации; эти операции не взаимозаменяемы. Сохранить в реализации правило: `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта. Сохранить в реализации правило: Метод чужой функции добавляют после `import` или через квалифицированное `M.f`; случайное создание новой локальной `f` не расширяет исходную таблицу методов.

Вопрос 19 из 20

Две реализации участка с `render(x::AbstractVector) = join(x, ",")` совпадают на обычных данных. Что необходимо проверить перед выпуском?

M.f(x::T)

Приёмка должна подтвердить, что `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта. Приёмка должна подтвердить, что `using M` делает доступными экспортированные имена, а `import M: f` разрешает добавлять методы к `f` без квалификации; эти операции не взаимозаменяемы. Приёмка должна подтвердить, что метод чужой функции добавляют после `import` или через квалифицированное `M.f`; случайное создание новой локальной `f` не расширяет исходную таблицу методов. Приёмка должна подтвердить, что совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`. Приёмка должна подтвердить, что `export` описывает публичные имена для `using`, но не скрывает остальные и не гарантирует стабильность API сам по себе.

Вопрос 20 из 20

Какое ограничение стоит прямо указать в документации к участку с `render(x::AbstractVector) = join(x, ",")`?

Указать в документации: Совпадение имени локальной функции с именем из соседнего модуля связывает объявление с той же таблицей методов без отдельного `import`. Указать в документации: `using M` делает доступными экспортированные имена, а `import M: f` разрешает добавлять методы к `f` без квалификации; эти операции не взаимозаменяемы. Указать в документации: `export` описывает публичные имена для `using`, но не скрывает остальные и не гарантирует стабильность API сам по себе. Указать в документации: Метод чужой функции добавляют после `import` или через квалифицированное `M.f`; случайное создание новой локальной `f` не расширяет исходную таблицу методов. Указать в документации: `module` создаёт отдельное глобальное пространство имён; квалифицированное имя остаётся доступным независимо от экспорта.