Экстеншены это вообще благодать, это добавление функционала классу без вторжения в сам класс

Мультиресиверы просто продолжают эту концепцию

кстати, а как вызывать экстеншн-функцию класса ?

ты под сервер разрабатываешь?

по работе сервер java, котлин хобби (swing)

кстати, а как вызывать экстеншн-функцию класса ?

только внутри?

по работе сервер java, котлин хобби (swing)

вот в свинге же есть, как в FX, специфичные для контейнеров параметры вьюх?

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

Насчет синтаксиса вроде даже обсуждение в ютраке есть двухгодичной давности

Насчет синтаксиса вроде даже обсуждение в ютраке есть двухгодичной давности

не видел этого тикета

вот в свинге же есть, как в FX, специфичные для контейнеров параметры вьюх?

ну, насколько я понял, да

не видел этого тикета

https://youtrack.jetbrains.com/issue/KT-10468

https://youtrack.jetbrains.com/issue/KT-10468

Вот, спасибо, только его нашёл

ну, насколько я понял, да

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

мне не про ресиверы интересно, а HKT

конкретно в котлине тайпклассы - это своего рода расширение понятия контекстов, которые создаются засчет экстеншенов

По-крайней мере, в том виде, в котором они предлагаются

вот так всегда - попросишь рассказать, а в ответ теория и математика... :(

meh

как оно практические задачи может облегчить? что-нибудь тупо бухгалтерское. или типо gui

как оно практические задачи может облегчить? что-нибудь тупо бухгалтерское. или типо gui

Я затрудняюсь ответить на этот вопрос

Тайпклассы - это просто фича, которая улучшает код

Так, ладно, окей

как оно практические задачи может облегчить? что-нибудь тупо бухгалтерское. или типо gui

(hkt) Сможешь фри-монады использовать и делать бизнес логику без DI и сайд-эффектов ?

(hkt) Сможешь фри-монады использовать и делать бизнес логику без DI и сайд-эффектов ?

> фри-монады oh my god, not again...

мне хочется верить, что это чудесная вещь, но виднеется везде что-то сферическое в вакууме

(hkt) Сможешь фри-монады использовать и делать бизнес логику без DI и сайд-эффектов ?

уже можно с Arrow

Ну такое, с костылями не нужно (там даже доки на них нет)

можно статеечку хоть на английском, но только без хаскела и монад

https://arrow-kt.io/docs/patterns/error_handling/ Не фри, но монады

можно статеечку хоть на английском, но только без хаскела и монад

Хм, могу только предложить: https://www.infoq.com/presentations/io-functional-side-effects http://blog.ploeh.dk/2017/08/07/f-free-monad-recipe/ https://youtu.be/U0lK0hnbc4U (Why the free Monad isn't free)

и да, Arrow привет

можно статеечку хоть на английском, но только без хаскела и монад

Ну вот я показывал как например без костылей, на чистом фп написать код, который позволит держать контекст, в данном случае сессию базы данных https://gist.github.com/eld0727/79714d2d79a21785ddf02b7c7e63648d

Все сервисы тут тайп классы

Тайп классы в "ковычках" конечно

кекус, сейчас бы везде Kind<,> и fix писать

Ну без hkt сорян

кекус, сейчас бы везде Kind<,> и fix писать

Как будто что-то плохое

Мне кажется он после этого сразу становится интересным 3 человекам, которые пришли из какого-то соседнего чата про фп

а когда спринг бут обсуждают, скольки людям это становится интересно?

в идеале хотелось бы как - вот программирет какой-нибудь Вася бухглатерию и формочки, хоть веб, хоть gui, и чувствует, что заколебался. и тут прилетает волшебный пони и говорит - Вася, тебе позарез нужны HKT и твой код станет в три раза короче и понятнее

а когда спринг бут обсуждают, скольки людям это становится интересно?

тоже правда :)

а когда спринг бут обсуждают, скольки людям это становится интересно?

за спринг бут обсуждает обычно не 3+1)

за спринг бут обсуждает обычно не 3+1)

4+2, да

https://youtrack.jetbrains.com/issue/KT-10468

надо воскресить и довести до keep

Ну вообще-то вместо срача можно придумывать новые идеи/концнпции, обсуждать возможность их реализации. Также вместо того что бы просто "тырить", предлагать модернизированные варианты "подсмотреного" у других, а не тупо тащить все из других яп

Ну вообще-то вместо срача можно придумывать новые идеи/концнпции, обсуждать возможность их реализации. Также вместо того что бы просто "тырить", предлагать модернизированные варианты "подсмотреного" у других, а не тупо тащить все из других яп

для этого надо быть нехило прокачанным в области теории ЯП

Вот тема про дополнительный ресивер интересна, и ее нужно продвигать

окей, раз уж пятничка, го

какие есть юзкейсы помимо UI?

надо набросать

какие есть юзкейсы помимо UI?

https://github.com/Miha-x64/reactive-properties/blob/master/sql/src/main/kotlin/net/aquadc/properties/sql/schema.kt#L165

https://github.com/Miha-x64/reactive-properties/blob/master/sql/src/main/kotlin/net/aquadc/properties/sql/schema.kt#L165

а на юзадж кинешь?

^ поменял ссылку

https://github.com/Miha-x64/reactive-properties/blob/master/logic-sample/src/main/kotlin/net/aquadc/propertiesSampleLogic/sql/schema.kt#L38

для этого надо быть нехило прокачанным в области теории ЯП

По спорам, мне кажется, у людей такое мнения о себе, они крутые спецы по разработке яп

на build.gradle.kts все же перекатился и от большой колбасы путей sql/src/main/kotlin/net/aquadc/properties/sql/schema.kt избавился на одном проекте?

А что исчезает? src? main? kotlin?

sql/src/properties/sql/schema.kt остается

https://github.com/Miha-x64/reactive-properties/blob/master/sql/src/main/kotlin/net/aquadc/properties/sql/schema.kt#L165

ащащащ вот это я понимаю полиморфное программирование

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

так, может это еще для каких-нибудь вложенных корутин подойдет?

ащащащ вот это я понимаю полиморфное программирование

реквестирую шутку про Go

Кто-нибудь видел статейки/рецепты/подходы про то, как написать "кастомную стейт-машину, для интерпретации корутин"? Ну те можно залезть в сорцы SequnceBuilder с его yield, но может кто-то уже разложил такой подход по полочкам.

Новый вариант ставить пробелы и прочие настройки оформления по какому запросу гуглить? Забыл, как это называется

новый вариант ставить проблеы?

codestyle?

Чтобы reformat code автоматически расставляло пробелы в 2 раза меньше. Это кодстайл называется?

ЖБ новый вариант настроек предложили, но я не могу найти описание этого события

официальный)

https://kotlinlang.org/docs/reference/coding-conventions.html

он про автоформатирование

это оно и есть

Ага спасибо. Видимо новый формат от старого не особо то отличается.

вот так всегда - попросишь рассказать, а в ответ теория и математика... :(

В простейшем виде typeclass - это такой интерфейс, реализацию которого ты можешь описать где угодно, а не только в определении класса. Пример на псевдоязыке: typeclass Hello<T> { // тайпкласс val hello: String } ... instance Hello<String> { // реализация для String. Описана отдельно от описания класса String override val hello: String get() = "Hello $this" } ... fun T greet(hi: Hello<T>) = println(hi.hello) // функция определённая для произвольной реализации тайпкласса ... greet("foo") // выведет "Hello foo" HKT или роды типов - описания структуры конструктора дженерик типа (сколько тайп параметров у дженерика, какой род у каждого тайп параметра) Пример для тайпкласса Functor: typeclass Functor<F<A>> { // F - дженерик (род * -> *), параметризуемый одним простым типом (род *) fun <B> map(f: (A) -> B): F<B> // если в языке есть роды типов, то возможны сигнатуры типа, где тайп параметр F параметризован другим тайп параметром } ... instance Functor<List<A>> { // теперь List является функтором и его можно использовать как аргумент любой функции, принимающей функтор override fun <B> map(f: (A) -> B): List<B> {...} }

То есть HKT нужны, чтобы более точные ограничения на дженерики описывать (map возвращает не просто какой-то F, а F<B>)

Абстракцию над данными, причем круче, чем интерфейсы

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

Используется примерно для таких задач: Есть у меня последовательность map вызовов, и хочу я, чтобы она работала для List, Sequence, Array и прочего, на что можно мэпиться. При этом без HKT придётся держать по одной реализации этой последовательности map для всех перечисленных вариантов. С HKT можно обойтись одной реализацией для функтора, которая будет работать для всего, что является функтором.

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

Одно другому не мешает. Тайпклассы конкретно в Котлине - это создание stateless контекста "на месте"

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

Вложенные контексты - это тайп класс трансформеры, если в терминологии тайп классов.

Используется примерно для таких задач: Есть у меня последовательность map вызовов, и хочу я, чтобы она работала для List, Sequence, Array и прочего, на что можно мэпиться. При этом без HKT придётся держать по одной реализации этой последовательности map для всех перечисленных вариантов. С HKT можно обойтись одной реализацией для функтора, которая будет работать для всего, что является функтором.

Плохой пример, тут они все наследуют Iterable. Разве что с масивом проблема.

Вложенные контексты - это тайп класс трансформеры, если в терминологии тайп классов.

Чего-то я не уверен

Логика в разных местах живет

Чего-то я не уверен

Ну в Haskell монад трансформеры как раз для вложенных контекстов разных монад используются

Одно другому не мешает. Тайпклассы конкретно в Котлине - это создание stateless контекста "на месте"

Я не спорю с идее тайп класса, но в пресловутом KEEP-87 там еще в добавок к тайп классам как-то много страшного мусора

Плохой пример, тут они все наследуют Iterable. Разве что с масивом проблема.

Ок, добавить сюда IO как функтор, Either

Не понимаю, как мультикониекст может заменить тайпклассы

Я не спорю с идее тайп класса, но в пресловутом KEEP-87 там еще в добавок к тайп классам как-то много страшного мусора

Там из мусора имплиситы разьве что. Без HKT тайп классы не очень нужны.

Не понимаю, как мультикониекст может заменить тайпклассы

Никак. На тайп классах можно сделать вложенные контексты. На вложенных контекстах тайп классы не получится.

Они по разному работают, но результата примерно одинаковый

Никак. На тайп классах можно сделать вложенные контексты. На вложенных контекстах тайп классы не получится.

Вот так и в кипе надо написать

Тайп классы - более мощная абстракция, чем абстрагирование контекста.

Под контексты надо исходно код по-другому писать

Под контексты надо исходно код по-другому писать

Под тайп классы - тоже

Я думаю, что это развитие в разные стороны. Не понятно, что лучше. Тайп классы довольно хорошо исследованы, а что можно наворотить на хорошей контекстной логике пока до конца не понятно. При чем тут чисто инженерно надо смотреть, никакая математика не поможет.

https://www.youtube.com/watch?v=v3dr4e54TLA

кто смотрит ?

или в оффтоп ?

Я думаю, что это развитие в разные стороны. Не понятно, что лучше. Тайп классы довольно хорошо исследованы, а что можно наворотить на хорошей контекстной логике пока до конца не понятно. При чем тут чисто инженерно надо смотреть, никакая математика не поможет.

Лично мне кажется, что хорошие фичи языка - те, для которых есть хорошо прописанная математика. Даёт уверенность, что внезапно оно в ногу не стрельнёт.

Ну, не то чтобы экстеншены собирались стрелять в ногу