SK
не, флюент это удобно)
Мне больше композиция объектов нравится в плане удобства
Size: a a a
2018 August 28
RK
Я вот с ходу вообще не вспомнил, когда я за 3 года фулл тайм на scala писал Nothing. Это скорее костыль языка 🙂
А вообще батенька Одерски предлагал юзать Nothing в методах, которые сразу кидают исключения
RK
Но такое
DA
val (a,b) = tuple
func(a)
func(b)
читается намного лучше, чем
func(tuple._1)
func(tuple._2)
Плюс заствляет именовать значения в тупле, это читается намного удобнее
func(a)
func(b)
читается намного лучше, чем
func(tuple._1)
func(tuple._2)
Плюс заствляет именовать значения в тупле, это читается намного удобнее
С
val (a,b) = tuple
func(a)
func(b)
читается намного лучше, чем
func(tuple._1)
func(tuple._2)
Плюс заствляет именовать значения в тупле, это читается намного удобнее
func(a)
func(b)
читается намного лучше, чем
func(tuple._1)
func(tuple._2)
Плюс заствляет именовать значения в тупле, это читается намного удобнее
Но ведь вавр такого не провайдит к сожалению
RM
Мне больше композиция объектов нравится в плане удобства
Покажи кодец
DA
А вообще батенька Одерски предлагал юзать Nothing в методах, которые сразу кидают исключения
Я что-то не очень понимаю, в чем смысл. Понятно, что Nothing и нужен для того, чтобы преодолеть более строгую типизацию scala. Так как даже ветка, где бросается исключение, должно в итоге иметь тот же тип возвращаемого элемета, что остальной код
DA
Именно поэтому и есть Nothing, который яявляется наследником любого класса
DA
Но объявлять сразу метод с возрвщаемым типом Nothing - это разве что в каких-то кишочках библиотек, но не в реальном коде
SK
Покажи кодец
Вот здесь я с композицией много балуюсь. Внешне выглядит может не так компактно как fluent API, но зато очень хорошо расширяется и адаптируется под требования без импакта на величину классов: https://github.com/skapral/puzzlerbot
DA
Но ведь вавр такого не провайдит к сожалению
Ну вот именно поэтому слепой перенос из scala в java не имеет смысла
SK
интересно увидеть пример vavr в контексте решения какой-то задачи
В примере выше я юзаю и вавр. Мне он гарантирует иммутабельность объектов с множественными зависимостями тогда, когда джавовыми средствами этого достигнуть было бы в разы сложнее.
SK
И Collection.unmodifiableList не выход в данном случае
SK
Потому что часто хочется иммутабельную коллекцию X плюс "еще вот этот вот элемент" без копирования.
DA
Но тут, кстати, возникает такая же ресурсня проблема, как и со scala. Если код поголовно юзает vavr, то нужных людей придется учить. И вот я не думаю, что научить хорошего джависта scala намного сложнее, чем изучить эту библиотеку.