DSL и функции с receiver — бесплатный тест онлайн

Вопрос 1 из 30

Что точнее описывает механику фрагмента «Контракты собственного DSL»?

// На ревью требуется объяснить причину поведения.
val page = html {
    p("hello")
    // raw(userInput)
}

Из правил языка или API следует, что следует мокировать каждый builder-метод и не создавать итоговую структуру. Механика примера описывается утверждением: Полезен лишь benchmark автодополнения IDE. Здесь действует следующее правило: Достаточно snapshot одной короткой строки: типовая система доказывает безопасность данных. Такой результат объясняют тем, что нужно проверять только количество receiver-лямбд в байткоде. DSL имеет два контракта: что компилируется и какую структуру создаёт; негативные compile-tests столь же важны, как runtime-тесты.

Вопрос 2 из 30

Как сделать ответственность во фрагменте «Builder до публикации конфигурации» понятной следующему разработчику?

// Сохраните назначение фрагмента, но укрепите его контракт.
fun routes(block: RouteRegistry.() -> Unit): RouteRegistry =
    RouteRegistry().apply(block).also { it.freeze() }

Перенести проверку в вызывающий код, исходя из того, что заморозка нужна только для уменьшения размера JSON-конфигурации. Проверять дубли маршрутов и зависимости при freeze, затем отдавать readers read-only структуру без builder-методов. Ограничиться поясняющим комментарием о том, что freeze автоматически распределяет маршруты по системным потокам. Оставить реализацию без изменений и закрепить тестом предположение: Она заменяет авторизацию и проверку конфликтов путей. Спрятать участок за вспомогательной функцией, сохранив предположение: После freeze любой обработчик становится suspend без изменения сигнатуры.

Вопрос 3 из 30

Как сделать ответственность во фрагменте «Минимальный type-safe builder» понятной следующему разработчику?

// Сохраните назначение фрагмента, но укрепите его контракт.
class Html {
    private val parts = mutableListOf<String>()
    fun p(text: String) { parts += "<p>$text</p>" }
    override fun toString() = parts.joinToString("")
}
fun html(block: Html.() -> Unit) = Html().apply(block).toString()
fun main() = println(html { p("Kotlin") })

Оставить реализацию без изменений и закрепить тестом предположение: Возникнет ошибка, потому что parts private для лямбды. Спрятать участок за вспомогательной функцией, сохранив предположение: Код не компилируется: лямбда receiver не может вызывать p без объекта. Открывать в receiver только допустимые операции и экранировать внешние данные, не смешивая построение структуры с небезопасным raw-текстом. Добавить защитную проверку перед фрагментом, поскольку будет выведено `<html>Kotlin</html>`, которое компилятор добавляет автоматически. Ограничиться поясняющим комментарием о том, что будет выведено имя класса Html, потому что apply игнорирует toString.

Вопрос 4 из 30

Какой редкий случай способен сломать наивную трактовку «Два receiver и явная метка»?

Добавить граничный тест на утверждение: Будет выведено `inner/inner`, поскольку метка относится к внутреннему run. Зафиксировать сценарий, где ожидается: Будет выведено `outer/inner`, потому что внешний receiver имеет приоритет. Проверить, сохраняется ли контракт, когда код не компилируется: два receiver с одинаковым свойством запрещены. Отдельно воспроизвести случай, в котором возникнет StackOverflowError при разрешении name. Extension от внешнего dispatch receiver может участвовать в разрешении вместе с членами внутреннего receiver и создавать неожиданный кандидат.

Вопрос 5 из 30

Предложенная правка для «Пользовательская infix-функция» звучит так: Использовать infix только для устойчивого бинарного отношения, которое естественно читается без точки и скобок. Какой недостаток важнее обсудить?

Главная цена решения — необходимость учитывать, что будет выведен `[4, 3, 2, 1]`, поскольку оператор меняет порядок аргументов. Граница полезности решения описывается условием: Функция будет вызвана дважды из-за отсутствия точки. Сопровождение усложнится, если окажется, что будет выведен `[1, 2, 3, 4]`, потому что infix делает диапазон включённым. После правки останется ограничение: Код не компилируется: infix разрешён только методам классов. Синтаксис улучшает предметную фразу, но скрывает обычный вызов и может ухудшить понимание при нетривиочном действии.

Вопрос 6 из 30

Что даёт общий `@DslMarker` вложенным builder-классам?

// Проследите фактическое выполнение без изменения кода.
@DslMarker annotation class UiDsl
@UiDsl class Screen { fun button(text: String) {} }
@UiDsl class Dialog { fun action(text: String) {} }
fun screen(block: Screen.() -> Unit) = Screen().apply(block)

Он закрывает неявный доступ к внешнему receiver того же DSL при наличии более близкого. Он запрещает вкладывать Dialog в Screen на уровне JVM. Он автоматически проверяет, что button вызывается до action. Он сериализует дерево DSL при выходе из блока. Он делает все функции builder приватными вне лямбды.

Вопрос 7 из 30

Что проверить отдельно, чтобы не принять «Builder до публикации конфигурации» за универсальное правило?

Захваченная лямбда обработчика всё ещё может ссылаться на изменяемый небезопасный объект, даже если сам реестр заморожен. Проверить крайний ввод, при котором freeze автоматически распределяет маршруты по системным потокам. Зафиксировать сценарий, где ожидается: После freeze любой обработчик становится suspend без изменения сигнатуры. Отдельно воспроизвести случай, в котором она заменяет авторизацию и проверку конфликтов путей. Добавить граничный тест на утверждение: Заморозка нужна только для уменьшения размера JSON-конфигурации.

Вопрос 8 из 30

Что проверить отдельно, чтобы не принять «Минимальный type-safe builder» за универсальное правило?

Проверить крайний ввод, при котором будет выведено имя класса Html, потому что apply игнорирует toString. Проверить, сохраняется ли контракт, когда будет выведено `<html>Kotlin</html>`, которое компилятор добавляет автоматически. Зафиксировать сценарий, где ожидается: Код не компилируется: лямбда receiver не может вызывать p без объекта. Типобезопасность DSL не защищает от логически неверного порядка элементов или внедрения данных, если API позволяет raw-вставку. Отдельно воспроизвести случай, в котором возникнет ошибка, потому что parts private для лямбды.

Вопрос 9 из 30

Предложенная правка для «Два receiver и явная метка» звучит так: Давать вложенным блокам предметные имена или применять `@DslMarker`, чтобы случайно не вызвать операцию внешнего builder. Какой недостаток важнее обсудить?

Обратная сторона изменения состоит в том, что будет выведено `outer/inner`, потому что внешний receiver имеет приоритет. Главная цена решения — необходимость учитывать, что возникнет StackOverflowError при разрешении name. Неявный receiver делает DSL компактным, но глубина больше двух уровней быстро снижает локальную понятность. Сопровождение усложнится, если окажется, что код не компилируется: два receiver с одинаковым свойством запрещены. После правки останется ограничение: Будет выведено `inner/inner`, поскольку метка относится к внутреннему run.

Вопрос 10 из 30

Какое значение напечатает «Пользовательская infix-функция»?

// Проследите фактическое выполнение без изменения кода.
infix fun Int.untilExclusive(other: Int) = this until other
fun main() = println((1 untilExclusive 4).toList())

Будет выведен `[4, 3, 2, 1]`, поскольку оператор меняет порядок аргументов. Будет выведен `[1, 2, 3]`: infix-вызов остаётся обычной функцией с одним параметром. Функция будет вызвана дважды из-за отсутствия точки. Будет выведен `[1, 2, 3, 4]`, потому что infix делает диапазон включённым. Код не компилируется: infix разрешён только методам классов.

Вопрос 11 из 30

Почему поведение «DSL marker и внешняя область» не является случайностью?

// На ревью требуется объяснить причину поведения.
@DslMarker annotation class UiDsl
@UiDsl class Screen { fun button(text: String) {} }
@UiDsl class Dialog { fun action(text: String) {} }
fun screen(block: Screen.() -> Unit) = Screen().apply(block)

Здесь действует следующее правило: Он автоматически проверяет, что button вызывается до action. Объяснение опирается на утверждение: Он запрещает вкладывать Dialog в Screen на уровне JVM. DSL marker ограничивает неявную видимость receiver-ов одной DSL-семьи; явный квалифицированный доступ возможен, если действительно нужен. Такой результат объясняют тем, что он сериализует дерево DSL при выходе из блока. Ключевым считают контракт: Он делает все функции builder приватными вне лямбды.

Вопрос 12 из 30

Что стоит исправить в «Контракты собственного DSL» перед слиянием?

// Сохраните назначение фрагмента, но укрепите его контракт.
val page = html {
    p("hello")
    // raw(userInput)
}

Добавить защитную проверку перед фрагментом, поскольку следует мокировать каждый builder-метод и не создавать итоговую структуру. Перенести проверку в вызывающий код, исходя из того, что полезен лишь benchmark автодополнения IDE. Отделить внутреннее дерево от rendering, чтобы тестировать структуру без хрупкой зависимости от пробелов и порядка атрибутов. Ограничиться поясняющим комментарием о том, что нужно проверять только количество receiver-лямбд в байткоде. Сохранить API и считать достаточным условие: Достаточно snapshot одной короткой строки: типовая система доказывает безопасность данных.

Вопрос 13 из 30

Какую обратную сторону имеет решение для «Минимальный type-safe builder»: Открывать в receiver только допустимые операции и экранировать внешние данные, не смешивая построение структуры с небезопасным raw-текстом?

Компромисс состоит в утверждении: Код не компилируется: лямбда receiver не может вызывать p без объекта. Новый риск связан с тем, что будет выведено `<html>Kotlin</html>`, которое компилятор добавляет автоматически. Обратная сторона изменения состоит в том, что возникнет ошибка, потому что parts private для лямбды. Практическое ограничение подхода: Будет выведено имя класса Html, потому что apply игнорирует toString. Builder даёт автодополнение и ранние ошибки, но создаёт собственный язык, который нужно документировать и поддерживать.

Вопрос 14 из 30

Какая строка будет выведена?

// Проследите фактическое выполнение без изменения кода.
class Outer { val name = "outer" }
class Inner { val name = "inner" }
fun demo() = Outer().run outer@ {
    Inner().run { "$name/${this@outer.name}" }
}
fun main() = println(demo())

Будет выведено `inner/outer`: немаркированное `name` относится к ближайшему receiver, метка выбирает внешний. Будет выведено `outer/inner`, потому что внешний receiver имеет приоритет. Возникнет StackOverflowError при разрешении name. Будет выведено `inner/inner`, поскольку метка относится к внутреннему run. Код не компилируется: два receiver с одинаковым свойством запрещены.

Вопрос 15 из 30

Какое объяснение результата «Пользовательская infix-функция» выдерживает проверку соседними случаями?

// На ревью требуется объяснить причину поведения.
infix fun Int.untilExclusive(other: Int) = this until other
fun main() = println((1 untilExclusive 4).toList())

Infix-функция — member или extension с одним обычным параметром без vararg/default; приоритет выражения отличается от привычных операторов. Механика примера описывается утверждением: Код не компилируется: infix разрешён только методам классов. Семантика фрагмента приводит к тому, что функция будет вызвана дважды из-за отсутствия точки. Причина результата в том, что будет выведен `[4, 3, 2, 1]`, поскольку оператор меняет порядок аргументов. Из правил языка или API следует, что будет выведен `[1, 2, 3, 4]`, потому что infix делает диапазон включённым.

Вопрос 16 из 30

Что следует изменить прежде всего во фрагменте «DSL marker и внешняя область»?

// Сохраните назначение фрагмента, но укрепите его контракт.
@DslMarker annotation class UiDsl
@UiDsl class Screen { fun button(text: String) {} }
@UiDsl class Dialog { fun action(text: String) {} }
fun screen(block: Screen.() -> Unit) = Screen().apply(block)

Маркировать все receiver-типы одного DSL и добавлять compile-test на запрещённый ошибочный вызов внешнего уровня. Добавить локальную обработку результата, потому что он сериализует дерево DSL при выходе из блока. Зафиксировать текущее поведение регрессионным тестом: Он делает все функции builder приватными вне лямбды. Передать ответственность владельцу вызова, предполагая, что он автоматически проверяет, что button вызывается до action. Оставить структуру прежней, документировав утверждение: Он запрещает вкладывать Dialog в Screen на уровне JVM.

Вопрос 17 из 30

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

Проверить, сохраняется ли контракт, когда следует мокировать каждый builder-метод и не создавать итоговую структуру. Добавить граничный тест на утверждение: Полезен лишь benchmark автодополнения IDE. Snapshot может подтвердить опасную raw-вставку как «ожидаемую», поэтому security-инвариант должен проверяться отдельно. Проверить крайний ввод, при котором нужно проверять только количество receiver-лямбд в байткоде. Считать опасной границей ситуацию, где достаточно snapshot одной короткой строки: типовая система доказывает безопасность данных.

Вопрос 18 из 30

Команда собирается проверять дубли маршрутов и зависимости при freeze, затем отдавать readers read-only структуру без builder-методов. Что придётся учитывать после внедрения в «Builder до публикации конфигурации»?

После правки останется ограничение: Freeze автоматически распределяет маршруты по системным потокам. Граница полезности решения описывается условием: Заморозка нужна только для уменьшения размера JSON-конфигурации. Главная цена решения — необходимость учитывать, что после freeze любой обработчик становится suspend без изменения сигнатуры. После внедрения придётся исходить из того, что она заменяет авторизацию и проверку конфликтов путей. Фаза сборки упрощает конкурентность и диагностику старта, но запрещает динамическое изменение без явного механизма новой версии конфигурации.

Вопрос 19 из 30

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

// На ревью требуется объяснить причину поведения.
class Outer { val name = "outer" }
class Inner { val name = "inner" }
fun demo() = Outer().run outer@ {
    Inner().run { "$name/${this@outer.name}" }
}
fun main() = println(demo())

Механика примера описывается утверждением: Будет выведено `inner/inner`, поскольку метка относится к внутреннему run. Во вложенных receiver scopes ближайший подходящий receiver обычно побеждает; метки и DSL markers делают выбор явным. Причина результата в том, что возникнет StackOverflowError при разрешении name. Из правил языка или API следует, что код не компилируется: два receiver с одинаковым свойством запрещены. Такой результат объясняют тем, что будет выведено `outer/inner`, потому что внешний receiver имеет приоритет.

Вопрос 20 из 30

Какая небольшая правка заметно повышает надёжность «Пользовательская infix-функция»?

// Сохраните назначение фрагмента, но укрепите его контракт.
infix fun Int.untilExclusive(other: Int) = this until other
fun main() = println((1 untilExclusive 4).toList())

Добавить локальную обработку результата, потому что будет выведен `[4, 3, 2, 1]`, поскольку оператор меняет порядок аргументов. Сохранить API и считать достаточным условие: Функция будет вызвана дважды из-за отсутствия точки. Использовать infix только для устойчивого бинарного отношения, которое естественно читается без точки и скобок. Зафиксировать текущее поведение регрессионным тестом: Код не компилируется: infix разрешён только методам классов. Передать ответственность владельцу вызова, предполагая, что будет выведен `[1, 2, 3, 4]`, потому что infix делает диапазон включённым.

Вопрос 21 из 30

Где упрощённое объяснение «DSL marker и внешняя область» перестаёт работать?

Проверить границу полезности утверждения: Он делает все функции builder приватными вне лямбды. Добавить тест на состояние, при котором он сериализует дерево DSL при выходе из блока. Воспроизвести редкий сценарий, где он автоматически проверяет, что button вызывается до action. Добавить граничный тест на утверждение: Он запрещает вкладывать Dialog в Screen на уровне JVM. Маркер не ограничивает обычные переменные и явно сохранённые ссылки на builder; это не песочница безопасности.

Вопрос 22 из 30

Какое ограничение сохранится после правки «Контракты собственного DSL»: Отделить внутреннее дерево от rendering, чтобы тестировать структуру без хрупкой зависимости от пробелов и порядка атрибутов?

Цена упрощения проявится, если достаточно snapshot одной короткой строки: типовая система доказывает безопасность данных. Решение оправдано лишь при условии: Полезен лишь benchmark автодополнения IDE. Практическое ограничение подхода: Нужно проверять только количество receiver-лямбд в байткоде. Compile-testing и структурные assertions требуют больше инфраструктуры, зато позволяют свободно менять формат вывода. Новый риск связан с тем, что следует мокировать каждый builder-метод и не создавать итоговую структуру.

Вопрос 23 из 30

Зачем builder замораживается перед публикацией?

// Проследите фактическое выполнение без изменения кода.
fun routes(block: RouteRegistry.() -> Unit): RouteRegistry =
    RouteRegistry().apply(block).also { it.freeze() }

Он отделяет однопоточную сборку от конкурентного чтения готового неизменяемого реестра. Она заменяет авторизацию и проверку конфликтов путей. Заморозка нужна только для уменьшения размера JSON-конфигурации. После freeze любой обработчик становится suspend без изменения сигнатуры. Freeze автоматически распределяет маршруты по системным потокам.

Вопрос 24 из 30

Как поведёт себя фрагмент «Минимальный type-safe builder» при указанных входных данных?

// Проследите фактическое выполнение без изменения кода.
class Html {
    private val parts = mutableListOf<String>()
    fun p(text: String) { parts += "<p>$text</p>" }
    override fun toString() = parts.joinToString("")
}
fun html(block: Html.() -> Unit) = Html().apply(block).toString()
fun main() = println(html { p("Kotlin") })

Код не компилируется: лямбда receiver не может вызывать p без объекта. Возникнет ошибка, потому что parts private для лямбды. Будет `<p>Kotlin</p>`: receiver `Html` предоставляет builder-операцию `p`. Будет выведено `<html>Kotlin</html>`, которое компилятор добавляет автоматически. Будет выведено имя класса Html, потому что apply игнорирует toString.

Вопрос 25 из 30

Какой соседний случай отличает устойчивое решение «Пользовательская infix-функция» от удачного примера?

Проверить соседний случай: Будет выведен `[1, 2, 3, 4]`, потому что infix делает диапазон включённым. Считать опасной границей ситуацию, где функция будет вызвана дважды из-за отсутствия точки. Цепочка нескольких infix-вызовов ассоциируется слева и может дать иной тип/смысл, чем ожидает читатель. Добавить регрессию на гипотезу: Будет выведен `[4, 3, 2, 1]`, поскольку оператор меняет порядок аргументов. Отдельно проверить предположение, что код не компилируется: infix разрешён только методам классов.

Вопрос 26 из 30

Команда собирается маркировать все receiver-типы одного DSL и добавлять compile-test на запрещённый ошибочный вызов внешнего уровня. Что придётся учитывать после внедрения в «DSL marker и внешняя область»?

Ограничение предотвращает структурные ошибки, но может потребовать явных меток в законных сложных сценариях. Главный риск формулируют так: Он делает все функции builder приватными вне лямбды. После правки останется ограничение: Он запрещает вкладывать Dialog в Screen на уровне JVM. После внедрения придётся исходить из того, что он сериализует дерево DSL при выходе из блока. Граница полезности решения описывается условием: Он автоматически проверяет, что button вызывается до action.

Вопрос 27 из 30

Какие проверки нужны DSL кроме сравнения итоговой строки?

// Проследите фактическое выполнение без изменения кода.
val page = html {
    p("hello")
    // raw(userInput)
}

Следует мокировать каждый builder-метод и не создавать итоговую структуру. Полезен лишь benchmark автодополнения IDE. Compile-test допустимых/запрещённых конструкций, структурное сравнение дерева и тест экранирования внешнего ввода. Нужно проверять только количество receiver-лямбд в байткоде. Достаточно snapshot одной короткой строки: типовая система доказывает безопасность данных.

Вопрос 28 из 30

Что в семантике Kotlin или используемого API объясняет «Builder до публикации конфигурации»?

// На ревью требуется объяснить причину поведения.
fun routes(block: RouteRegistry.() -> Unit): RouteRegistry =
    RouteRegistry().apply(block).also { it.freeze() }

Конфигурационный DSL лучше строить до запуска приложения, валидировать целиком и публиковать как устойчивый снимок. Семантика фрагмента приводит к тому, что заморозка нужна только для уменьшения размера JSON-конфигурации. Контракт здесь понимают так: Она заменяет авторизацию и проверку конфликтов путей. Причина результата в том, что после freeze любой обработчик становится suspend без изменения сигнатуры. Механика примера описывается утверждением: Freeze автоматически распределяет маршруты по системным потокам.

Вопрос 29 из 30

Что в семантике Kotlin или используемого API объясняет «Минимальный type-safe builder»?

// На ревью требуется объяснить причину поведения.
class Html {
    private val parts = mutableListOf<String>()
    fun p(text: String) { parts += "<p>$text</p>" }
    override fun toString() = parts.joinToString("")
}
fun html(block: Html.() -> Unit) = Html().apply(block).toString()
fun main() = println(html { p("Kotlin") })

Семантика фрагмента приводит к тому, что будет выведено `<html>Kotlin</html>`, которое компилятор добавляет автоматически. Поведение связывают с правилом: Возникнет ошибка, потому что parts private для лямбды. Механика примера описывается утверждением: Будет выведено имя класса Html, потому что apply игнорирует toString. Причина результата в том, что код не компилируется: лямбда receiver не может вызывать p без объекта. Type-safe builder использует receiver-функции и обычную типовую проверку вместо строковой интерпретации команд.

Вопрос 30 из 30

Какой рефакторинг делает поведение «Два receiver и явная метка» предсказуемее?

// Сохраните назначение фрагмента, но укрепите его контракт.
class Outer { val name = "outer" }
class Inner { val name = "inner" }
fun demo() = Outer().run outer@ {
    Inner().run { "$name/${this@outer.name}" }
}
fun main() = println(demo())

Ограничиться поясняющим комментарием о том, что код не компилируется: два receiver с одинаковым свойством запрещены. Давать вложенным блокам предметные имена или применять `@DslMarker`, чтобы случайно не вызвать операцию внешнего builder. Сохранить API и считать достаточным условие: Будет выведено `outer/inner`, потому что внешний receiver имеет приоритет. Спрятать участок за вспомогательной функцией, сохранив предположение: Будет выведено `inner/inner`, поскольку метка относится к внутреннему run. Добавить защитную проверку перед фрагментом, поскольку возникнет StackOverflowError при разрешении name.