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

A>Имеется ввиду, что там матчинг можно делать для любого класса с конструктором определённого вида, а в Скала — только для case класса. Соответственно, если есть аллергия на case class, то придётся имплисит ковертор в тупл делать с потерей исходного типа.

Ну, это какая-то вкусовщина. Считай что Колтиновские классы с дефолтным конструктором все являются кэйс-классами. Вот и все.

Технически для реализации ПМ нужно не бирка "кэйс", а информация о соответствии параметров конструктора (можно даже выдуманного) полям/свойствам типа (даже классом быть не обязательно). Это нужно так как в ПМ образец описывает объект через его конструктор. Так что нужна любая форма задания этого соответственно. Дефолтный конструктор прекрасно решает эту задачу для описываемых вновь типов.

A>В Котле этого якобы не надо — за что он Сайбераксу понравился.

На мой взгляд без разницы. Все равно МП возможен только для определенного рода типов. По типам Явы он точно будет невозможен.

A>Ну а я считаю, что хочешь делать п.матчинг — ну и поставь case class, делов-то.

Согласен. Хотя лучше было бы предусмотреть возможность делать ПМ по любому типу. В Немрле это возможно, например.

A>А библиотечные Java-классы, которые трогать нельзя и там и там придётся оборачивать вспомогательным кодом, который пишется один раз и всё — тоже не вижу проблемы.

При оборачивании будут потери в скорости и качестве контроля со стороны компилятора. Только для замкнутых кейс-классов (они же варианты немерла или ограниченные объединения МЛ-я) можно обеспечить контроль компилятора. А без этого будет много граблей.