Сопоставление с образцом в Java: InstanceOf (JEP 305)

Был у меня когда-то проект специализированной IDE на основе Eclipse, внутри которого разрабы из IBM любили навалить instanceof по любому поводу. Это был настоящий ад: передаешь условный Subtype в метод, который ожидает Supertype, — и ничего не работает. И приходится полдня копаться в исходниках, чтобы где-то в глубине найти метод с пачкой instanceof, среди которых просто нет кейса на Subtype.

Scala 3: избавление от implicit. Extension-методы и неявные преобразования

Стоит добавить, что во второй скале на каждый вызов расширения создается объект неявного класса

x -> y
//эквивалентно
new ArrowAssoc(x).->(y)

В третьей версии создается функция верхнего уровня

x ~> y
//эквивалентно
~>(x, y)

Идиоматичный Kotlin, набор хороших практик

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

Почему стоит полностью переходить на Ceylon или Kotlin (часть 2)

1. Очень жаль, что и в Ceylon, и в Kotlin под деструктуризацией понимается только деструктуризация кортежей.
2. Не совсем понятно, как связаны union types и перегрузка операторов.

3. В Scala, эквивалентный код будет выглядеть следующим образом:
   

   val singleton: Tuple1[Long] = new Tuple1(1)
   

   
   

   Это неправда, идеоматический вариант:
   

   val singleton = (1)
   

   
   new Tuple1 на практике не встречается.

Идиоматичный Kotlin, набор хороших практик

Категорически поддерживаю:

Избегайте проверок типов

Вот только почему после этого идёт as?, ведь это и есть проверка типа.