Объект scala.language

объект language

Объект scala.language управляет доступными программисту языковыми возможностями, как предложено в документе SIP-18.

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

import language.postfixOps // or language._
List(1, 2, 3) reverse

Языковые возможности:

• dynamics позволяет определять переопределения вызовов с использованием Dynamic тракта

• existentials позволяет писать экзистенциальные типы

• higherKinds позволяет писать типы высшего порядка

• implicitConversions позволяет определять неявные методы и члены

• postfixOps позволяет использовать постфиксные операторы (не рекомендуется)

• reflectiveCalls позволяет использовать структурные типы

• experimental содержит новые возможности, которые еще не были протестированы в производстве

Экспериментальные языковые возможности

Источник

объект experimental

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

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

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

Языковые возможности

Источник

неявный ленивый val dynamics: dynamics

Только там, где эта возможность включена, могут быть определены прямые или косвенные подклассы тракта scala.Dynamic. Если dynamics не включена, определение класса, тракта или объекта, имеющего Dynamic в качестве базового тракта, отбрасывается компилятором.

Выбор динамических членов существующих подклассов тракта Dynamic не затрагивается; они могут использоваться где угодно.

Зачем вводить эту возможность? Для обеспечения гибких DSL и удобного взаимодействия с динамическими языками.

Зачем контролировать её? Динамический выбор членов может подорвать статическую проверяемость программ. Кроме того, динамический выбор членов часто зависит от рефлексии, которая не доступна на всех платформах.

Источник

неявный ленивый val existentials: existentials

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

Экзистенциальные типы с синтаксисом дикого типа, таким как List[_], или Map[String, _] не затронуты.

Зачем сохранять эту возможность? Экзистенциальные типы необходимы для осмысления диких типов и сырых типов Java, а также стёртых типов значений во время выполнения.

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

Источник@deprecated("higherKinds больше не нужно импортировать явно", "2.13.1")

неявный ленивый val higherKinds: higherKinds

В случае включения этой возможности, типы высшего порядка могут быть записаны. Если higherKinds не включена, тип высшего порядка, такой как F[A], вызовет предупреждение от компилятора.

Зачем сохранять эту возможность? Типы высшего порядка позволяют определять очень общие абстракции, такие как функтор, монада или стрелка. Значительное количество расширенных библиотек опирается на них. Типы высшего порядка также лежат в основе усилий scala-virtualized по созданию высокопроизводительных параллельных DSL посредством стадирования.

Зачем контролировать её? Типы высшего порядка в Scala приводят к полнофункциональной системе типов, где гарантия завершения компиляции больше не гарантируется. Они, как правило, полезны в основном для вычислений на уровне типов и для высокоуровневых общих шаблонов проектирования. Уровень абстракции, подразумеваемый этими шаблонами проектирования, часто является барьером для понимания новыми пользователями кодовой базы Scala. Некоторые синтаксические аспекты типов высшего порядка трудно понять неосведомлённым, и выведение типов менее эффективно для них, чем для обычных типов. Поскольку мы ещё не полностью удовлетворены ими, возможно, некоторые аспекты типов высшего порядка изменятся в будущих версиях Scala. Поэтому явное включение также служит предупреждением о том, что код, включающий типы высшего порядка, может потребовать небольшого пересмотра в будущем.

Источник

неявный ленивый val implicitConversions: implicitConversions

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

Неявное преобразование — это неявное значение типа унарной функции A => B, или неявный метод, имеющий в своей первой секции параметров один, неявный параметр. Примеры:

implicit def stringToInt(s: String): Int = s.length
implicit val conv = (s: String) => s.length
implicit def listToX(xs: List[T])(implicit f: T => X): X = ...

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

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

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

Источник

неявный ленивый val postfixOps: postfixOps

Только там, где эта возможность включена, разрешён постфиксный синтаксис оператора (expr op). Если postfixOps не включена, выражение с постфиксным синтаксисом отбрасывается компилятором.

Зачем сохранять эту возможность? Постфиксная запись сохраняется только для обратной совместимости. Исторически некоторые DSL, написанные на Scala, нуждаются в этом синтаксисе.

Зачем контролировать её? Постфиксные операторы плохо взаимодействуют с выводом точек с запятой. Большинство программистов избегают их именно по этой причине. Постфиксный синтаксис ассоциируется с неправильным использованием инфиксной записи, a op1 b op2 c op3, которая может быть труднее для чтения, чем обычный вызов метода с разумным использованием скобок. Рекомендуется не включать эту возможность, за исключением устаревшего кода.

Источник

неявный ленивый val reflectiveCalls: reflectiveCalls

В случае включения этой возможности, доступ к членам структурных типов, требующих рефлексии, поддерживается. Если reflectiveCalls не включена, выражение, требующее рефлексии, вызовет предупреждение от компилятора.

Структурный тип — это тип вида Parents { Decls }, где Decls содержит объявления новых членов, которые не переопределяют ни один член в Parents. Для доступа к одному из этих членов необходим рефлексивный вызов.

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

Зачем контролировать её? Рефлексия не доступна на всех платформах. Популярные инструменты, такие как ProGuard, сталкиваются с проблемами при работе с ней. Даже там, где рефлексия доступна, рефлексивный диспетчер может привести к неожиданному снижению производительности.

Классы-типы

Источник@compileTimeOnly("`3.0` может быть использован только на этапе компиляции в операторах импорта")

объект 3.0

Установить версию исходного кода на 3.0.

Источник@compileTimeOnly("`3.0-migration` может быть использован только на этапе компиляции в операторах импорта")

объект 3.0-migration

Установить версию исходного кода на 3.0-migration.

Исходный код@compileTimeOnly("`3.1` может быть использован только на этапе компиляции в операторах импорта")

object 3.1

Установить версию источника в 3.1

Исходный код@compileTimeOnly("`3.1-migration` может быть использован только на этапе компиляции в операторах импорта")

object 3.1-migration

Установить версию источника в 3.1-migration.

Исходный код@compileTimeOnly("`adhocExtensions` может быть использован только на этапе компиляции в операторах импорта")

object adhocExtensions

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

Зачем контролировать эту возможность? Расширения по умолчанию, как правило, следует избегать, так как они, как правило, не могут полагаться на «внутренний» контракт между классом и его расширениями. Только открытые классы должны указывать такой контракт. Расширения по умолчанию могут перестать работать для будущих версий расширяемого класса, так как расширяемый класс свободен изменять свою реализацию без ограничения внутренним контрактом.

Зачем это разрешать? Расширение по умолчанию иногда может быть необходимо, например, при моделировании класса в фреймворке тестирования или для решения ошибки или отсутствия функции в исходном классе. Тем не менее, такие расширения должны быть ограничены по объёму и явно документированы. Именно поэтому для них требуется импорт языка.

Исходный код@compileTimeOnly("`deprecated` может быть использован только на этапе компиляции в операторах импорта")

object deprecated

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

Исходный код@compileTimeOnly("`future` может быть использован только на этапе компиляции в операторах импорта")

object future

Исходный код@compileTimeOnly("`future-migration` может быть использован только на этапе компиляции в операторах импорта")

object future-migration

Исходный код@compileTimeOnly("`noAutoTupling` может быть использован только на этапе компиляции в операторах импорта")

object noAutoTupling

При импорте отключается автоматическое преобразование в кортежи.

Зачем контролировать эту возможность? Автоматическое преобразование в кортежи может привести к запутанному и хрупкому коду при наличии перегрузок. В частности, могут быть выбраны неожиданные перегрузки, и добавление новых перегрузок может изменить выбор перегрузки неожиданным образом.

Зачем это разрешать? Невозможность автоматического преобразования в кортежи трудно согласовать с операторами, принимающими кортежи.

Исходный код@compileTimeOnly("`strictEquality` может быть использован только на этапе компиляции в операторах импорта")

object strictEquality

При импорте отключается слабая проверка на равенство с помощью eqAny.

Почему эта функция разрешена и контролируется? Из соображений совместимости и миграции строгое равенство реализуется по запросу. Дополнительную информацию см. в связанной документации.

Исходный код@compileTimeOnly("`unsafeNulls` может быть использован только на этапе компиляции в операторах импорта")

object unsafeNulls

Небезопасные Null для явных Null внутри области «небезопасно», Null рассматривается как подтип всех ссылочных типов.