Object 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. Если динамика не включена, определение класса, трейта или объекта с 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.

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

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

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

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

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

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

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

Только при включении этого флага можно писать типы высшего порядка.

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

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

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

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

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

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

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

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

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

Экспериментальный объект содержит функции, которые недавно были добавлены, но ещё не были полностью протестированы в рабочей среде.

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

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