Это какие-то привычки из js? Почему не должно быть?

.isArchived все же лучше чем .status == STATUS_ARCHIVED

.isArchived все же лучше чем .status == STATUS_ARCHIVED

when (status) { ...

.filter { it.isArchived }

.filter { it.isArchived }

.filter(Message::isArchived)

разве здесь нельзя создать 1 раз экстеншен

Можно делать что угодно, но если хочешь расширить функциональность сначала надо подумать, почему бы это не сделать в самом классе. Если, скажем область видимости нужна другая - тогда да. В остальных случаях это лишь попытка натянуть структурное программирование на ООП экосистему.

А профит какой?

Имхо, нет, если мне надо например собрать 3 строки в одну для вывода, и юзать это часто, я бы делал метод

Оч зависит от идеологии, data class это по сути сумма типов из функциональщине, которая просто описывает данные, если следовать этой логике, то в data class'е не должно быть никакой логики, в том числе каких то вычислимых полей

Оч зависит от идеологии, data class это по сути сумма типов из функциональщине, которая просто описывает данные, если следовать этой логике, то в data class'е не должно быть никакой логики, в том числе каких то вычислимых полей

Покласть экстеншен в том же файле с дата классом ))

Кароч вкусовщина

Оч зависит от идеологии, data class это по сути сумма типов из функциональщине, которая просто описывает данные, если следовать этой логике, то в data class'е не должно быть никакой логики, в том числе каких то вычислимых полей

Произведение типов же

Произведение типов же

ой, да

типа кортеж?

типа кортеж?

Именно

sealed - сумма

Оч зависит от идеологии, data class это по сути сумма типов из функциональщине, которая просто описывает данные, если следовать этой логике, то в data class'е не должно быть никакой логики, в том числе каких то вычислимых полей

Если следовать этой логике, то пишите на хаскеле. Зачем здесь следовать этой логике и усложнять жизнь?

Ну да, произведение. Из этого не следует ничего.

Ну да, произведение. Из этого не следует ничего.

Классно выдираете из контекста ?

Сори, не все прочитал

Если следовать этой логике, то пишите на хаскеле. Зачем здесь следовать этой логике и усложнять жизнь?

я ни говорил что так и только так надо делать. А сказал что если мы следуем определенной идеологии, то так будет правильнее

я ни говорил что так и только так надо делать. А сказал что если мы следуем определенной идеологии, то так будет правильнее

но никто не следует фп идеологии фп ?

?‍♂️

но никто не следует фп идеологии фп ?

А можно было бы избежать части костылей

Можно делать что угодно, но если хочешь расширить функциональность сначала надо подумать, почему бы это не сделать в самом классе. Если, скажем область видимости нужна другая - тогда да. В остальных случаях это лишь попытка натянуть структурное программирование на ООП экосистему.

а я бы наоборот, задумался бы, можно ли это сделать вне класса (если это data class, то это надо делать 100%)

иначе можно заполучить портянку с тычячей хелпер методов, прикрутить state и сайдэффекты

нууууу... Нет.

нууууу... Нет.

вспомни rx

забыл как страшный сон

А можно было бы избежать части костылей

наш мир, увы, не идеален, и приходится "костылить". Полный ФП подход не всегда хорош, иногда и хуже будет. Нужно продумывать архитектуру, хоть иногда, а не просто круды гонять ?

вообще хорошее правило большого пальца - подумать, а вынес ли бы ты этот хелпер в интерфейс

никто не выносит в LIst методы типа foreach или zipWithNext

Можно делать что угодно, но если хочешь расширить функциональность сначала надо подумать, почему бы это не сделать в самом классе. Если, скажем область видимости нужна другая - тогда да. В остальных случаях это лишь попытка натянуть структурное программирование на ООП экосистему.

А котлин себя позиционирует как ООП? Или всё таки как мультипарадигму?

никто не выносит в LIst методы типа foreach или zipWithNext

Да не, бред какой-то

А котлин себя позиционирует как ООП? Или всё таки как мультипарадигму?

«Котлин ООП, потому что никто не знает, что есть функциональный язык» — как-то так у них написано

А котлин себя позиционирует как ООП? Или всё таки как мультипарадигму?

как прагмадигму

А кстати как оргументировали создатели языка, почему в data class по дефолту не val?

Метод copy как бы намекает, что оно должно быть так

потому что глубокую иммутабельность при удовлетворительном интеропе гарантировать всё равно нельзя?..

А кстати как оргументировали создатели языка, почему в data class по дефолту не val?

чтобы было как в Scala?

пора уже признать что Kotlin просто better Scala?

пора уже признать что Kotlin просто better Scala?

Кривая_рожа.жпг

https://twitter.com/kotlin/status/1052956211119906816

Метод copy как бы намекает, что оно должно быть так

copy можно использовать что бы просто клонировать объекты, типа java clone, только амного лучше. Правда не берусь сказать на сколько это часто нужно

copy можно использовать что бы просто клонировать объекты, типа java clone, только амного лучше. Правда не берусь сказать на сколько это часто нужно

clone() нужен для массивов и мутабельных коллекций, то есть в низкоурокневой дичи

copy можно использовать что бы просто клонировать объекты, типа java clone, только амного лучше. Правда не берусь сказать на сколько это часто нужно

Ну это очень утрированно и в целом не правда, clone не даёт определить новые значения для полей. Это как раз для удобства создание измененных иммутабельных данных. Например в реактивщине принять сообщение и кинуть изменённое дальше

Ну это очень утрированно и в целом не правда, clone не даёт определить новые значения для полей. Это как раз для удобства создание измененных иммутабельных данных. Например в реактивщине принять сообщение и кинуть изменённое дальше

я про то что иногда нужно сдублировать модель, и хочеться как-то покороче. Но это 1 на 1 000 000 случай

А кстати как оргументировали создатели языка, почему в data class по дефолту не val?

вроде как JB стараются делать чтобы между обычными и "специальными" классами была минимальная разница

я про то что иногда нужно сдублировать модель, и хочеться как-то покороче. Но это 1 на 1 000 000 случай

А у вас в основном какие классы используются мутабельные или иммутабельные?

А у вас в основном какие классы используются мутабельные или иммутабельные?

стараюсь делать иммутабельные (изначально их делаю), но иногда приперает и проще сделать мутабельным (1-2 проперти)

хотя, когда JavaFX там модельки (и не только) подругому не сделаешь, интертоп...

Хелб, как такое переписать на Котлин?

Вчера идентичный вопрос задавали. inputStream.copyTo(outputStream).

Вчера идентичный вопрос задавали. inputStream.copyTo(outputStream).

ничеси как круто

реализация функции-расширение длинее java варианта)

Хелб, как такое переписать на Котлин?

А в чем сложность?

Этот вопрос задают с завидной регулярностью

ну если тупо, то while (true) { val length = input.read(buffer) if (length < 0) break output.write(buffer, 0, length) }

ну что, (п̶о̶с̶л̶е̶д̶н̶и̶й̶ ) крайний RC?

ну что, (п̶о̶с̶л̶е̶д̶н̶и̶й̶ ) крайний RC?

Этим зачёркиванием и исправлением ты сделал мне очень больно. :(

ну кто знает, вдруг тут суеверные

релиз, небось, будет на школьных каникулах

В Беларуси например любят к 7 ноября что-нибудь открывать. Главное, чтобы релиз к 7 ноября не приурочили ?‍♀️

В Беларуси например любят к 7 ноября что-нибудь открывать. Главное, чтобы релиз к 7 ноября не приурочили ?‍♀️

Почему ?))

Релизы редко связаны с датами СССР(большинство проектов потому что пишется за бугор)

релиз, небось, будет на школьных каникулах

Чтобы больше тестеров было )))

А кстати как оргументировали создатели языка, почему в data class по дефолту не val?

Потому что такого нет в синтаксисе обычных классов. А добавлять отделенный синтаксис с чем-то неявным в Котлине не любят.

Чтобы больше тестеров было )))

Лол ?

А кстати как оргументировали создатели языка, почему в data class по дефолту не val?

Что "по дефолту не val"?

Что "по дефолту не val"?

data class (noVal: Int) - компилятор ошибку кинет

data class (noVal: Int) - компилятор ошибку кинет

А. Ну и зачем?) Там же можно и var, была бы путаница.

А. Ну и зачем?) Там же можно и var, была бы путаница.

ну и чт бы var не было, полность иммутабено

ну и чт бы var не было, полность иммутабено

Такое себе.

Иммутабельность - не всегда плохо же.

скажем data class (value) == data class(val value)

+ сам так считаю

скажем data class (value) == data class(val value)

У этого синтаксиса есть другой смысл

У этого синтаксиса есть другой смысл

так не я задаю вопросы, я ответил раньше что JB стараются делать минимальные различие между похожими вещами

так не я задаю вопросы, я ответил раньше что JB стараются делать минимальные различие между похожими вещами

Ну да, чтобы меньше путаницы было, мне кажется это норм

ну что, (п̶о̶с̶л̶е̶д̶н̶и̶й̶ ) крайний RC?

хотелось бы верить

«Котлин ООП, потому что никто не знает, что есть функциональный язык» — как-то так у них написано

Как так никто не знает, что есть функциональный язык, если есть готовые реализации чисто функциональных языков? ФП парадигма основана двух операциях: лямбда абстракция - построение функции по выражению путём связывания переменной выражения с параметром функции. бета редукция - применение функции к значению. Из этих двух операций конструируются основные операции для практического применения. Например: композиция двух функций - комбинатор вида \f g x -> f (g x) рекурсия через Y комбинатор (комбинатор неподвижной точки) После этого любое вычисление (программа) сводится к последовательному построению функций, комбинированию их с помощью комбинаторов и применению к аргументам. Основная сложность при этом - побочные эффекты, так как функции в данной парадигме чистые => побочные эффекты всегда находятся несколько за пределами ФП: в рамках чистого ФП можно только описать, какой побочный эффект мы хотим, но не выполнить его. Итого: чистая ФП парадигма имеет следующие отличительные черты: 1. Замыкания, они же лямбда абстракции. Через них реализуется, в том числе, инкапсуляция. 2. Рекурсия как единственный способ реализации итеративных вычислений. 3. Ссылочная прозрачность - результат применения любой функции зависит только от значения параметра, к которому её применили. По мне, так определение даже более чёткое, чем для ООП, с его инкапсуляцией, наследованием и полиморфизмом.

Как так никто не знает, что есть функциональный язык, если есть готовые реализации чисто функциональных языков? ФП парадигма основана двух операциях: лямбда абстракция - построение функции по выражению путём связывания переменной выражения с параметром функции. бета редукция - применение функции к значению. Из этих двух операций конструируются основные операции для практического применения. Например: композиция двух функций - комбинатор вида \f g x -> f (g x) рекурсия через Y комбинатор (комбинатор неподвижной точки) После этого любое вычисление (программа) сводится к последовательному построению функций, комбинированию их с помощью комбинаторов и применению к аргументам. Основная сложность при этом - побочные эффекты, так как функции в данной парадигме чистые => побочные эффекты всегда находятся несколько за пределами ФП: в рамках чистого ФП можно только описать, какой побочный эффект мы хотим, но не выполнить его. Итого: чистая ФП парадигма имеет следующие отличительные черты: 1. Замыкания, они же лямбда абстракции. Через них реализуется, в том числе, инкапсуляция. 2. Рекурсия как единственный способ реализации итеративных вычислений. 3. Ссылочная прозрачность - результат применения любой функции зависит только от значения параметра, к которому её применили. По мне, так определение даже более чёткое, чем для ООП, с его инкапсуляцией, наследованием и полиморфизмом.

Я бы не хотел вступать в спор, тем более, что это не мои слова и я слабо подготовлен. Но я не согласен :)

Я бы не хотел вступать в спор, тем более, что это не мои слова и я слабо подготовлен. Но я не согласен :)

С чем? С тем, что под ФП есть стройное математическое обоснование, которое разработали в середина 20 века, а что такое ООП - каждый создатель языка понимает по своему? Так это факт, а факты - вещь упрямая.

С чем? С тем, что под ФП есть стройное математическое обоснование, которое разработали в середина 20 века, а что такое ООП - каждый создатель языка понимает по своему? Так это факт, а факты - вещь упрямая.

А я бы поспорил, но не вижу предмета спора. Т/к понимаю цитату таким образом - неочевидно, что в котлин прячется фп

С чем? С тем, что под ФП есть стройное математическое обоснование, которое разработали в середина 20 века, а что такое ООП - каждый создатель языка понимает по своему? Так это факт, а факты - вещь упрямая.

по поводу сильной мат базы под фп согласен на 100

у любителей ооп банда четырех это как святое писание

у любителей ооп банда четырех это как святое писание

Под ооп точно так есть мат формализмы

хотя я не знаю о чем тут спорили, мне лень читать чатик выше, о чем спор, господа?)

у любителей ооп банда четырех это как святое писание

у ненавистников, ты хотел сказать?

С чем? С тем, что под ФП есть стройное математическое обоснование, которое разработали в середина 20 века, а что такое ООП - каждый создатель языка понимает по своему? Так это факт, а факты - вещь упрямая.

Ну с ооп то тоже все понятно вроде, есть объекты, которые общаются с друг другом сообщениями. А то что сейчас понимается под ООП это уже отдельная тема

у любителей ооп банда четырех это как святое писание

Вчера у Венката было высказывание про эту книжку. Типа что это "бесполезный список рецептов, который не работает если следовать дословно")

у любителей ооп банда четырех это как святое писание

Сборник костылей?

сборник именованных костылей)

:D

сборник именованных костылей)

the best :)