Объект scala.language

Проверка двух объектов на неравенство.

Эквивалентно x.hashCode за исключением упакованных числовых типов и null. Для числовых типов возвращает хэш-значение, согласованное с равенством значений: если два экземпляра типа значения сравниваются как true, то ## вернёт одно и то же хэш-значение для каждого из них. Для null возвращает хэш-код, где null.hashCode выбрасывает NullPointerException.

Выражение x == that эквивалентно if (x eq null) that eq null else x.equals(that).

Приведение типа объекта-получателя к типу T0.

Обратите внимание, что успех приведения типов во время выполнения зависит от семантики стирания Scala. Поэтому выражение 1.asInstanceOf[String] выбросит ClassCastException во время выполнения, а выражение List(1).asInstanceOf[List[String]] — нет. В последнем примере, поскольку тип аргумента стирается во время компиляции, невозможно проверить, соответствуют ли содержимое списка запрошенному типу.

Создаёт копию объекта-получателя.

По умолчанию реализация метода clone зависит от платформы.

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

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

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

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

Проверяет, является ли аргумент (that) ссылкой на объект-получатель (this).

Метод eq реализует отношение эквивалентности на не-нулевых экземплярах AnyRef, и обладает тремя дополнительными свойствами:

• Он согласован: для любых не-нулевых экземпляров x и y типа AnyRef, многократные вызовы x.eq(y) последовательно возвращают true или последовательно возвращают false.
• Для любого не-нулевого экземпляра x типа AnyRef, вызовы x.eq(null) и null.eq(x) возвращают false.
• null.eq(null) возвращает true.

При переопределении методов equals или hashCode важно обеспечить согласованность их поведения с равенством ссылок. Поэтому, если два объекта являются ссылками друг на друга (o1 eq o2), они должны быть равны друг другу (o1 == o2) и должны иметь одинаковое хэш-значение (o1.hashCode == o2.hashCode).

Метод равенства для ссылочных типов. По умолчанию делегирует вызов eq.

См. также equals в scala.Any.

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

Существенные типы с синтаксисом универсальных типов, такими как List[_], или Map[String, _] не затрагиваются.

Почему функция нужна? Существенные типы необходимы для понимания универсальных типов и типов-сырых типов Java и стиранных типов значений времени выполнения.

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

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

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

Возвращает представление класса объекта во время выполнения.

Метод hashCode для ссылочных типов. См. hashCode в scala.Any.

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

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

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

В случае включения этой функции разрешены определения неявных преобразований. Если 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.

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

Проверяет, соответствует ли динамический тип объекта-получателя типу T0.

Обратите внимание, что результат проверки определяется в соответствии с семантикой стирания Scala. Поэтому выражение 1.isInstanceOf[String] вернет false, а выражение List(1).isInstanceOf[List[String]] вернет true. В последнем примере, поскольку аргумент типа стирается во время компиляции, проверить, содержат ли элементы списка указанный тип, невозможно.

Эквивалентно !(this eq that).

Разбуживает единственную нить, ожидающую монитор объекта-получателя.

Разбуживает все нити, ожидающие монитор объекта-получателя.

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

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

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

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

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

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

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

Создаёт строковое представление этого объекта. Стандартное представление зависит от платформы. На платформе Java это конкатенация имени класса, символа «@» и хэш-кода объекта в шестнадцатеричном формате.

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

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

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