Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, VladD2, Вы писали:
VD>>Справидливости ради надо заметить, что их множественное наследование так же требует ручного разрешения конфликтов. Если в у двух наследников есть один и тот же метод, то нужно его обязательно переопределить.
C>Но в Скале для этого сделали целый механизм трейтов, с кучей исключений и непоняток. В Котлине, зато, всё тупо и примитивно. А делегирование явно выделено в отдельный паттерн, а не вмешано в трейты.
Согласен, что для понимания подход Котлин (так и хочется котлетой называть
) лучше. Но чисто технически — это те же самые трейтсы. Просто для них нашли более понятную форуму.
Я именно это и хотел сказать. Идея с эмуляция МН мне очень даже нравится. Единственное, что она не очень вяжется с явой. Интерфейсов то в явном виде нет. У людей могут возникнуть непонятки.
C>>>Case-классы я вообще в принципе ненавижу. Это запредельная кривость.
VD>>А что ты предлагаешь? Варианты/объеденения как в классихческих ФП?
C>Мне не нравится явное выделение их в специальную сущность. В Скале они используются для:
C>1) Специальный случай для классов-значений, с автогенерируемыми hashCode, equals и т.п. Нафиг не надо — должен быть общий механизм.
C>2) Только для них, по сути, в языке и встроено деструктурирование для PM (ну ещё для списков). Что тоже должно быть доступно для всех классов, в том числе и legacy-бинов.
Почти уверен, что у Котлина те же ограничения и то же поведение. Ну, разве что hashCode и equals не нужно реализовывать.
C>>>В Scala PM на практике требует использования case-классов. В Kotlin оно реализовано, как я вижу, через деструктурирующие функции, в том числе для обычных бинов.
VD>>По-моему ты ошибаешься. В Kotlin точно так же описываются классы с неявным конструктором, что аналогично кейс-классам (вид в профиль).
C>http://confluence.jetbrains.net/display/Kotlin/Pattern+matching Всё что требуется от классов для участия в PM — это иммутабельность.
Что-то я там такого не увидел. По-моему, ты что-то путаешь.
Потом я с автором языка общался пару месяцев назад, и он мне четка сказал, что описание берется из определения класса. Вряд ли что-то за это время изменилось.
C>Ну и явная возможность задавать деструктуризатор, тогда как в Scala надо делать case-класс и implicit-конвертор в него.
Какие еще на фиг деструкторы? Это ты про Decomposer functions?
A>>>>Скала у всех на слуху, а взлетает долго. Мне кажется этот ещё дольше будет взлетать.
C>>>Scala слишком кривая местами.
VD>>Например?
C>Управляющие конструкции (в Kotline есть нелокальный return),
Чё? Это ты о инлайн-функциях что ли? Можно пример?
C> trait'ы, case class'ы.
Проблемы то где?
C>>>Kotlin выглядит как почищенная от мусора Scala.
VD>>Во многом так оно и есть. В прочем, местами перечистили. Лябды какие-то кривенькие.
C>Из примера в http://confluence.jetbrains.net/display/Kotlin/Functions :
C>C>strings filter {it.length == 5} sortby {it} map {it.toUpperCase()}
C>
И что? А если нужно два параметра? И зачем эти скобки? Сравни Шарп:
from s in strings where s.length == 5 orderby s select s.toUpperCase()
или без сахара:
strings.Where(s => s.length == 5).OrderBy(s => s).Select(s => s.toUpperCase())
Можно вбить внятные имена. Нет непонятных скобок. Нет проблем, если параметров у лямбды должно быть несколько.
C>Это ещё и получше будет, чем в Scala. Особенно учитывая наличие анонимных типов (aka "именованые туплы").
Как только речь заходит о случаях которые не укладываются в сахар с it, то все становится не так радужно.
C>>>Я, как программист на Scala, читаю программы на Kotlin вообще сразу — всё знакомое. Но при этом ВСЕ мои проблемы в Скале исправлены в Котлине.
VD>>Дык описал бы эти проблемы и то как они решены в Kotlin.
C>Частично описал здесь: http://rsdn.ru/forum/philosophy/4349959.aspxАвтор: Cyberax
Дата: 20.07.11
Там описано что тебе понравилось. Но про проблемы ни слова.
C>В общем, если эти товарищи сейчас не будут пытаться запихать незапихиваемое, то получится очень неплохой язык. С метапрограммированием лучше подождать, так как слишком уж опасная это штука. Как implicit'ы в Scala.
Ничего там опасного нет. Это домыслы. Авторы на грани. Мысли есть. Но есть страх неизведанного (как у тебя).
