Здравствуйте, VladD2, Вы писали:

C>>1) Специальный случай для классов-значений, с автогенерируемыми hashCode, equals и т.п. Нафиг не надо — должен быть общий механизм.
C>>2) Только для них, по сути, в языке и встроено деструктурирование для PM (ну ещё для списков). Что тоже должно быть доступно для всех классов, в том числе и legacy-бинов.
VD>Почти уверен, что у Котлина те же ограничения и то же поведение. Ну, разве что hashCode и equals не нужно реализовывать.
У Котлина как минимум PM по всем иммутабельным типам делается, в том числе и legacy. Генерация hashCode/equals — пока непонятно.

VD>>>По-моему ты ошибаешься. В Kotlin точно так же описываются классы с неявным конструктором, что аналогично кейс-классам (вид в профиль).
C>>http://confluence.jetbrains.net/display/Kotlin/Pattern+matching Всё что требуется от классов для участия в PM — это иммутабельность.
VD>Что-то я там такого не увидел. По-моему, ты что-то путаешь.
VD>Потом я с автором языка общался пару месяцев назад, и он мне четка сказал, что описание берется из определения класса. Вряд ли что-то за это время изменилось.
То есть?

C>>Ну и явная возможность задавать деструктуризатор, тогда как в Scala надо делать case-класс и implicit-конвертор в него.
VD>Какие еще на фиг деструкторы? Это ты про Decomposer functions?
Деструктуризаторы, не деструкторы — это стандартный термин в PM. Т.е. функции, разбирающие объект на составные части, которые можно использовать в PM.

В Kotlin:

decomposer fun Any?.Tree() : (Tree?, Tree?)? 
{ 
  if (this is Tree) return (left=this.left, right=this.right) return null 
}
//И дальше спокойно матчим

В Скале:

//Есть класс:
class Tree {
   val left : Tree;
   val right : Tree;
}

//Хочешь PM по этому классу делать? А вот обломись!

//Нужно делать что-то типа:
implicit object TreeWrapper {
   def unapply(t : Tree) = {
      (t.left, t.right)
  }
}

//Теперь можно делать так:
val tr : Tree = ....;

match(tr) {
    case TreeWrapper(t) => Console.print(t._1, t._2);
}
//Если хотим вместо неименованых параметров _1, _2 
//использовать left и right - то нужно делать отдельный case-class

Стоит ли говорить, что после этого использование PM при работе с legacy-кодом превращается в ужас?

C>>Управляющие конструкции (в Kotline есть нелокальный return),
VD>Чё? Это ты о инлайн-функциях что ли? Можно пример?
Ага. http://confluence.jetbrains.net/display/Kotlin/Nonlocal+returns+and+jumps (раздел "Break and continue is custom control structures") — в Скале такое не получается.

VD>И что? А если нужно два параметра? И зачем эти скобки? Сравни Шарп:
VD>

VD>from s in strings where s.length == 5 orderby s select s.toUpperCase()
VD>

VD>или без сахара:
VD>

VD>strings.Where(s => s.length == 5).OrderBy(s => s).Select(s => s.toUpperCase())
VD>

VD>Можно вбить внятные имена. Нет непонятных скобок. Нет проблем, если параметров у лямбды должно быть несколько.
Различие с Котлином будет только в скобках. По мне — пофиг.

C>>Это ещё и получше будет, чем в Scala. Особенно учитывая наличие анонимных типов (aka "именованые туплы").
VD>Как только речь заходит о случаях которые не укладываются в сахар с it, то все становится не так радужно.
То есть?

C>>Частично описал здесь: http://rsdn.ru/forum/philosophy/4349959.aspx

Автор: Cyberax
Дата: 20.07.11

VD>Там описано что тебе понравилось. Но про проблемы ни слова.
То что понравилось — в Скале неудобно.

C>>В общем, если эти товарищи сейчас не будут пытаться запихать незапихиваемое, то получится очень неплохой язык. С метапрограммированием лучше подождать, так как слишком уж опасная это штука. Как implicit'ы в Scala.
VD>Ничего там опасного нет. Это домыслы. Авторы на грани. Мысли есть. Но есть страх неизведанного (как у тебя).
Не, ну про implicit так же говорили. А получился ужастик в итоге.