Принципы развития Kotlin

Принципы прагматичного развития

Kotlin создан как прагматичный инструмент для программистов. Прагматичный подход к развитию языка отражают следующие принципы:

• Поддерживать современность языка с течением времени.

• Поддерживать постоянную обратную связь с пользователями.

• Сделать переход на новые версии простым и удобным для пользователей.

Поскольку эти принципы важны для понимания развития Kotlin, рассмотрим их подробнее.

Поддержка современности языка. Мы понимаем, что со временем в системах накапливается устаревший код. То, что когда-то было передовой технологией, сегодня может безнадежно устареть. Чтобы язык оставался актуальным и соответствовал потребностям пользователей и их ожиданиям, он должен развиваться. Это подразумевает не только добавление новых возможностей, но и постепенный отказ от тех, которые больше не рекомендуются для промышленной разработки и устарели.

Удобный переход на новые версии. Несовместимые изменения, например удаление элементов языка, могут привести к болезненному переходу с одной версии на другую, если вносить их без должной осторожности. Мы всегда будем заранее объявлять о таких изменениях, помечать элементы как устаревшие и предоставлять инструменты для автоматической миграции до внесения изменений. К моменту изменения языка мы хотим, чтобы большая часть кода уже была обновлена, а переход на новую версию не вызывал проблем.

Обратная связь. Циклы устаревания требуют значительных усилий, поэтому мы хотим свести к минимуму количество несовместимых изменений в будущем. Помимо того, что мы полагаемся на собственное здравое суждение, мы считаем, что лучший способ проверить дизайн — опробовать его на практике. Прежде чем высекать что-либо в камне, мы хотим испытать это в реальных условиях. Поэтому мы используем любую возможность, чтобы сделать ранние версии наших решений доступными в промышленных версиях языка, но в одном из нестабильных статусов: Experimental, Alpha или Beta. Такие возможности нестабильны: их могут изменить в любой момент, а пользователи, решившие ими воспользоваться, явно подтверждают готовность иметь дело с возможными проблемами при переходе на будущие версии. Эти пользователи предоставляют бесценную обратную связь, которую мы используем для дальнейшей работы над дизайном и его совершенствования.

Несовместимые изменения

Если при переходе с одной версии на другую какой-либо код, который раньше работал, перестает работать, это несовместимое изменение языка (иногда его называют «ломающим изменением»). В некоторых случаях можно спорить о том, что именно означает «перестает работать», но к таким изменениям определенно относятся следующие:

• Код, который успешно компилировался и выполнялся, теперь отклоняется с ошибкой (во время компиляции или компоновки). Сюда относятся удаление языковых конструкций и введение новых ограничений.

• Код, который выполнялся нормально, теперь выбрасывает исключение.

К менее очевидным случаям, относящимся к «серой зоне», относятся обработка граничных случаев по-другому, выбрасывание исключения другого типа, изменение поведения, наблюдаемого только через рефлексию, изменение недокументированного или неопределенного поведения, переименование бинарных артефактов и прочее. Иногда такие изменения крайне важны и значительно влияют на процесс перехода; иногда они несущественны.

Вот несколько примеров того, что определенно не является несовместимым изменением:

• Добавление новых предупреждений.

• Добавление новых языковых конструкций или ослабление ограничений для существующих.

• Изменение приватных и внутренних API, а также других деталей реализации.

Принципы поддержки современности языка и удобного перехода на новые версии подразумевают, что несовместимые изменения иногда необходимы, но вводить их следует осторожно. Наша цель — заранее информировать пользователей о предстоящих изменениях, чтобы они могли без проблем перенести свой код.

В идеале о каждом несовместимом изменении следует сообщать с помощью предупреждения во время компиляции, которое отображается в проблемном коде (обычно его называют предупреждением об устаревании), и предоставлять средства для автоматической миграции. Таким образом, идеальный процесс перехода выглядит следующим образом:

• Переход на версию A (в которой объявляется об изменении)

  • Получение предупреждений о предстоящем изменении

  • Миграция кода с помощью инструментов

• Переход на версию B (в которой вносится изменение)

  • Отсутствие каких-либо проблем

На практике некоторые изменения невозможно точно обнаружить во время компиляции, поэтому о них нельзя сообщить с помощью предупреждений. Однако пользователи как минимум будут уведомлены в примечаниях к выпуску версии A о том, что изменение появится в версии B.

Принятие решений

JetBrains, первоначальный создатель Kotlin, развивает язык при поддержке сообщества и в сотрудничестве с Kotlin Foundation.

За всеми изменениями языка программирования Kotlin следит ведущий дизайнер языка (в настоящее время — Михайл Зареченский). Ведущий дизайнер принимает окончательное решение по всем вопросам, связанным с развитием языка. Кроме того, несовместимые изменения в полностью стабильных компонентах должны быть одобрены комитетом по языку, созданным при Kotlin Foundation (в настоящее время в его состав входят Джеффри ван Гог, Вернер Дитль и Михайл Зареченский).

Комитет по языку принимает окончательные решения о том, какие несовместимые изменения будут внесены и какие конкретные меры следует принять, чтобы переход пользователей проходил как можно проще. При этом он руководствуется рекомендациями комитета по языку.

Выпуск языковых возможностей

Как описано в разделе процесс выпуска Kotlin, языковые возможности появляются в выпусках языка (2. x. 0) или в следующих за ними выпусках инструментов (2. x. 20).

Мы стараемся обеспечивать совместимость выпусков языка и инструментов, поэтому изменения компилятора в основном представляют собой оптимизации, а также добавление или удаление предупреждений. Нестабильные возможности могут добавляться, удаляться или изменяться в любое время.

В выпусках языка часто появляются новые возможности, нестабильные возможности получают стабильный статус, а ранее объявленные устаревшими возможности могут быть удалены или изменены.

Библиотеки

Язык не может существовать без своей экосистемы, поэтому мы уделяем особое внимание тому, чтобы обеспечить плавное развитие библиотек.

В идеале новую версию библиотеки можно использовать как «прямую замену» старой версии. Это означает, что обновление бинарной зависимости не должно ничего нарушать, даже если приложение не перекомпилируется (это возможно при динамической компоновке).

С одной стороны, для этого компилятор должен обеспечивать определенные гарантии стабильности бинарного интерфейса приложения (ABI) в условиях раздельной компиляции. Поэтому каждое изменение языка оценивается с точки зрения бинарной совместимости.

С другой стороны, многое зависит от того, насколько осторожно авторы библиотек подходят к выбору безопасных изменений. Поэтому авторам библиотек крайне важно понимать, как изменения исходного кода влияют на совместимость, и следовать рекомендациям, позволяющим сохранять стабильность API и ABI библиотек. При рассмотрении изменений языка с точки зрения развития библиотек мы исходим из следующих предположений:

• В коде библиотек всегда следует явно указывать типы возвращаемых значений публичных и защищенных функций и свойств, не полагаясь на вывод типов для публичного API. Незначительные изменения в выводе типов могут непреднамеренно изменить типы возвращаемых значений и привести к проблемам с бинарной совместимостью.

• Перегруженные функции и свойства одной библиотеки должны выполнять по существу одно и то же. Изменения в выводе типов могут привести к тому, что в местах вызова станут известны более точные статические типы, и это повлияет на выбор перегрузки.

Авторы библиотек могут использовать аннотации @Deprecated и @RequiresOptIn, чтобы контролировать развитие публичного API. Обратите внимание: @Deprecated(level=HIDDEN) можно использовать для сохранения бинарной совместимости даже для объявлений, удаленных из API.

Кроме того, по соглашению пакеты с именем "internal" не считаются частью публичного API. Весь API, размещенный в пакетах с именем "experimental", считается нестабильным и может измениться в любой момент.

Мы развиваем стандартную библиотеку Kotlin (kotlin-stdlib) для стабильных платформ согласно изложенным выше принципам. Изменения контрактов ее API проходят те же процедуры, что и изменения самого языка.

Параметры компилятора

Параметры командной строки, принимаемые компилятором, также относятся к публичному API, поэтому к ним применяются те же соображения. Поддерживаемые параметры (не имеющие префикса "-X" или "-XX") можно добавлять только в выпусках языка; перед удалением их следует должным образом объявить устаревшими. Параметры "-X" и "-XX" являются экспериментальными и могут добавляться и удаляться в любое время.

Инструменты совместимости

По мере удаления устаревших возможностей и исправления ошибок меняется исходный язык, и старый код, который не был должным образом перенесен, может перестать компилироваться. Обычный цикл устаревания предоставляет достаточно времени для перехода, а даже после его завершения и включения изменения в стабильную версию остается возможность скомпилировать неперенесенный код.