Прекращайте, ребят.

Ты чего, в этом канале срач это основное

Превратить котлин в скалу - плохая идея

Срачи сюда https://t.me/pofftop

@pofftop (сейчас как удалим все ?)

Создайте чат @fp_jvm и туда всех?

Создайте чат @fp_jvm и туда всех?

Вот да

Превратить котлин в скалу - плохая идея

так уже поздно. Гораздо лучше идея - сделать из котлина нормальное фп+ооп

И там обсуждения как здорово без циклов а 2к18 (кек)

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

Ладно, согласен, тут я чутка неправильно выразился

Превратить котлин в скалу - плохая идея

слава богу никто не пытается)

так уже поздно. Гораздо лучше идея - сделать из котлина нормальное фп+ооп

не надо

Пытаются

Там POC тайпклассов в котлине выкатили https://github.com/arrow-kt/kotlin/pull/6

так уже поздно. Гораздо лучше идея - сделать из котлина нормальное фп+ооп

scala 2?

так уже поздно. Гораздо лучше идея - сделать из котлина нормальное фп+ооп

Если под "нормальным фп" подразумевается "сделать так, чтобы хорошо жилось любителям эрроу" — не надо, пожалуйста.

@fp_jvm погнали, пацаны

Ибо им-то хорошо житься будет, а всем остальным резко станет грустно.

Если под "нормальным фп" подразумевается "сделать так, чтобы хорошо жилось любителям эрроу" — не надо, пожалуйста.

+

типоклассы вполне себе оопешная штука, это просто адаптер для интерфейса

Если под "нормальным фп" подразумевается "сделать так, чтобы хорошо жилось любителям эрроу" — не надо, пожалуйста.

а, чщерт

никто ведь не протестует против дополнительной поддержки паттерна делегации в котлине

типоклассы вполне себе оопешная штука, это просто адаптер для интерфейса

Я больше про имплиситы

Там POC тайпклассов в котлине выкатили https://github.com/arrow-kt/kotlin/pull/6

если честно - то я мало что понял, надо вчитываться

Я больше про имплиситы

не нужны! упаси боже)

а, вот про имплиситы сразу не увидел

вон отсюда arrow)

Там POC тайпклассов в котлине выкатили https://github.com/arrow-kt/kotlin/pull/6

тащемта (не костыльной) реализации тайпклассов в скале нет. ждём дотти

У скалистов вроде припекает от котлина они на нем не пишут(вроде бы)

я скалист, от котлина не припекает (только от некоторых недопилов)

тащемта (не костыльной) реализации тайпклассов в скале нет. ждём дотти

А чем дотти будет принципиально отличаться в этом плане?

Синтаксисом криваярожажпг

А чем дотти будет принципиально отличаться в этом плане?

когерентностью жи

когерентностью жи

не помню чтобы когерентность обещали

я скалист, от котлина не припекает (только от некоторых недопилов)

Исключение?

Исключение?

Да как бы у скалистов вообще не печёт от котлина

Не, ну погодите. Тайп классы - это тайп классы. Имплиситы - это имплиситы. Не надо мух с котлетами смешивать. Тайп классы про реализацию контрактов по месту. Есть у тебя контракт (интерфейс, он же тайп класс) A, есть класс B. Ты описываешь, как классом B реализуется контракт A и можешь везде, где требуется A использовать B. При этом декларацию класса B ты не модифицируешь. Имплиситы про динамическое связывание свободных переменных в лямбдах (подробнее не скажу, ещё не копал особо эту тему в haskell, так как там она в рамках language extension сделана).

Не, ну погодите. Тайп классы - это тайп классы. Имплиситы - это имплиситы. Не надо мух с котлетами смешивать. Тайп классы про реализацию контрактов по месту. Есть у тебя контракт (интерфейс, он же тайп класс) A, есть класс B. Ты описываешь, как классом B реализуется контракт A и можешь везде, где требуется A использовать B. При этом декларацию класса B ты не модифицируешь. Имплиситы про динамическое связывание свободных переменных в лямбдах (подробнее не скажу, ещё не копал особо эту тему в haskell, так как там она в рамках language extension сделана).

Тащемта тут речь не про шашкелёвые иплиситы, а про сам концепт "не явного". Что в данном случае можно сказать про инстансы тайпклассов

Не, ну погодите. Тайп классы - это тайп классы. Имплиситы - это имплиситы. Не надо мух с котлетами смешивать. Тайп классы про реализацию контрактов по месту. Есть у тебя контракт (интерфейс, он же тайп класс) A, есть класс B. Ты описываешь, как классом B реализуется контракт A и можешь везде, где требуется A использовать B. При этом декларацию класса B ты не модифицируешь. Имплиситы про динамическое связывание свободных переменных в лямбдах (подробнее не скажу, ещё не копал особо эту тему в haskell, так как там она в рамках language extension сделана).

так в этом ПРе имплиситы добавлены, чтобы тайпклассы было удобнее юзать, есессна они идеологически не связаны

Не, ну погодите. Тайп классы - это тайп классы. Имплиситы - это имплиситы. Не надо мух с котлетами смешивать. Тайп классы про реализацию контрактов по месту. Есть у тебя контракт (интерфейс, он же тайп класс) A, есть класс B. Ты описываешь, как классом B реализуется контракт A и можешь везде, где требуется A использовать B. При этом декларацию класса B ты не модифицируешь. Имплиситы про динамическое связывание свободных переменных в лямбдах (подробнее не скажу, ещё не копал особо эту тему в haskell, так как там она в рамках language extension сделана).

т.е. неявно (implicitly) вместо B подставляется реализация контракта A для B

т.е. неявно (implicitly) вместо B подставляется реализация контракта A для B

Не вижу здесь какой-то неявности в подстановке реализации. Две реализации B => A в рамках одного пространства имён существовать не может, это компилятор проверяет. В результате мы всегда легко отслеживаем единственную реализацию.

у тебя нет _явной_ функции из тайпкласса D на объекте класса C

и тем более ты нигде _явно_ не прописываешь что для вызова этой функции ты используешь конкретный инстанс тайпкласса

у тебя нет _явной_ функции из тайпкласса D на объекте класса C

Так её и неявной нету. Это даункаст из D в C получается. Есть явная стрелка из C в D, а не наоборот.

и тем более ты нигде _явно_ не прописываешь что для вызова этой функции ты используешь конкретный инстанс тайпкласса

Прописываешь. Как раз там, где вызываешь и прописываешь.

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

нет

у тебя просто "появляется" метод на классе A из тайпкласса B

у тебя просто "появляется" метод на классе A из тайпкласса B

Ну как же он просто появляется, если ты его декларируешь в описании реализации A => B

Он не из ниоткуда магически "появляется". Он из вполне конкретной и единственной декларации появляется.

ты его декларируешь в тайпклассе и реализуешь в каком-то инстансе не понятно где

ну и: myClassInstance.methodFromTypeClass() // не явно with(typeClassInstance) { myClassInstance.methodFromTypeClass() } // явно

ты его декларируешь в тайпклассе и реализуешь в каком-то инстансе не понятно где

Вот есть у нас такой примерно псевдокод с типичным использованием тайп классов (это не код на Kotlin): typeclass A { fun foo(): String } .... instance A(B) { override fun foo(): String = "foo" } ... fun A.printFoo() = println(foo()) ... val b: B = ... b.printFoo() Не пойму, где тут неявность?

Декларация instance A(B) у нас единственная, это компилятор вполне может проверить.

неявность в том что ты ЯВНО не указываешь что printFoo у теья от тайпкласса и тем более не указываешь инстанс

extension функции внезапно тоже не явные

неявность в том что ты ЯВНО не указываешь что printFoo у теья от тайпкласса и тем более не указываешь инстанс

Ну так у нас любой подключенный класс из внешней библиотеки можно считать неявным. У тебя "из ниоткуда" появляются конструкторы класса, и вообще возможность с ним работать.

тогда иплиситы в скале - явные

это пожалуй всё что я могу на эту тему ещё написать

тогда иплиситы в скале - явные

Нет. Имплиситы как раз неявные, так как описывают, какой конкретный инстанс использовать по умолчанию вместо тайп класса. А в моём примере выше имплиситов и прочих дефолтов нет. Неявным он станет, если написать default A = b ... printFoo() Вот тут уже для printFoo ресисвер определяется неявно.

Нет. Имплиситы как раз неявные, так как описывают, какой конкретный инстанс использовать по умолчанию вместо тайп класса. А в моём примере выше имплиситов и прочих дефолтов нет. Неявным он станет, если написать default A = b ... printFoo() Вот тут уже для printFoo ресисвер определяется неявно.

как же это не явные: import myImplicit myObject.callMethodWithMyImplicit вполне явно - нужен импорт

как же это не явные: import myImplicit myObject.callMethodWithMyImplicit вполне явно - нужен импорт

Как резолвится конфликт имён на импортах имплиситов? Импортированный имплисит можно дальше по коду переопределить?

в классе есть такая штука private val api: Rest by inject() Хочу это замокать. В голову приходит вариант сделать это как var api: Rest by inject() а в тесте подменить controller.api = mock Есть ли другие варианты ?

в классе есть такая штука private val api: Rest by inject() Хочу это замокать. В голову приходит вариант сделать это как var api: Rest by inject() а в тесте подменить controller.api = mock Есть ли другие варианты ?

А inject замокать в тестах нельзя?

в классе есть такая штука private val api: Rest by inject() Хочу это замокать. В голову приходит вариант сделать это как var api: Rest by inject() а в тесте подменить controller.api = mock Есть ли другие варианты ?

DI делается как раз для того, чтобы не трогать класс, когда меняются его зависимости.

ERROR: S client not available

Как резолвится конфликт имён на импортах имплиситов? Импортированный имплисит можно дальше по коду переопределить?

там не по именам а по типам, можно на стадии компиляции разные весёлости получить: diverging implicit declaration, ...

в классе есть такая штука private val api: Rest by inject() Хочу это замокать. В голову приходит вариант сделать это как var api: Rest by inject() а в тесте подменить controller.api = mock Есть ли другие варианты ?

constructor injections?

constructor injections?

Да, возможно посмотрю в сторону этого

там не по именам а по типам, можно на стадии компиляции разные весёлости получить: diverging implicit declaration, ...

Ок. Имплисит, импортированный для некоторого типа, можно дальше по коду переопределить?

если в кратце то - нет

в классе есть такая штука private val api: Rest by inject() Хочу это замокать. В голову приходит вариант сделать это как var api: Rest by inject() а в тесте подменить controller.api = mock Есть ли другие варианты ?

class Foo( val bar: Bar = get<Bar>() ) ... val foo = Foo(mock)

Вроде должно

Вроде должно

это tornadoFX class HomeController : Controller() { private val api: Rest by inject() где inject inline fun <reified T> inject( overrideScope: Scope = scope, vararg params: Pair<String, Any?> ): ReadOnlyProperty<Component, T> where T : Component, T : ScopedInstance = inject(overrideScope, params.toMap()) пока не представляю как замокать ?

это tornadoFX class HomeController : Controller() { private val api: Rest by inject() где inject inline fun <reified T> inject( overrideScope: Scope = scope, vararg params: Pair<String, Any?> ): ReadOnlyProperty<Component, T> where T : Component, T : ScopedInstance = inject(overrideScope, params.toMap()) пока не представляю как замокать ?

А. Я думал коин. :)

это tornadoFX class HomeController : Controller() { private val api: Rest by inject() где inject inline fun <reified T> inject( overrideScope: Scope = scope, vararg params: Pair<String, Any?> ): ReadOnlyProperty<Component, T> where T : Component, T : ScopedInstance = inject(overrideScope, params.toMap()) пока не представляю как замокать ?

А что делает inject, которому делегируется вызов? По сути это «старый добрый» DI на синглтонах со всеми присущими ему проблемами.

это tornadoFX class HomeController : Controller() { private val api: Rest by inject() где inject inline fun <reified T> inject( overrideScope: Scope = scope, vararg params: Pair<String, Any?> ): ReadOnlyProperty<Component, T> where T : Component, T : ScopedInstance = inject(overrideScope, params.toMap()) пока не представляю как замокать ?

На первый взгляд кажется, что лучше заменить дефолтный DI на koin (и там делать норм constructor-inj) Тут немного описано https://edvin.gitbooks.io/tornadofx-guide/content/part2/Dependency%20Injection.html

На первый взгляд кажется, что лучше заменить дефолтный DI на koin (и там делать норм constructor-inj) Тут немного описано https://edvin.gitbooks.io/tornadofx-guide/content/part2/Dependency%20Injection.html

Спасибо, попробую

А то как-то "нечисто" по-моему с таким подходом

это tornadoFX class HomeController : Controller() { private val api: Rest by inject() где inject inline fun <reified T> inject( overrideScope: Scope = scope, vararg params: Pair<String, Any?> ): ReadOnlyProperty<Component, T> where T : Component, T : ScopedInstance = inject(overrideScope, params.toMap()) пока не представляю как замокать ?

Я бы на гите сделал issues

это tornadoFX class HomeController : Controller() { private val api: Rest by inject() где inject inline fun <reified T> inject( overrideScope: Scope = scope, vararg params: Pair<String, Any?> ): ReadOnlyProperty<Component, T> where T : Component, T : ScopedInstance = inject(overrideScope, params.toMap()) пока не представляю как замокать ?

Нужно сделать свой контекст для теста и туда проинжектить мок сервиса

Нужно сделать свой контекст для теста и туда проинжектить мок сервиса

+

Нужно сделать свой контекст для теста и туда проинжектить мок сервиса

Ну нахрена в тесты DI тащить то?.. ?

Ну нахрена в тесты DI тащить то?.. ?

Так он же только для этого и нужен, разве нет?

Если мы говорим, про di-framework (аля koin/kodein/dagger2), то он нужен что бы ручками граф не собирать. А для тестов - достаточно зависимости в конструктор принимать.

Ну нахрена в тесты DI тащить то?.. ?

Я бы сказал что он хочет тестировать в контроллере и вю

Я бы сказал что он хочет тестировать в контроллере и вю

*зачем ему тестировать

scala 2?

Better Scala

Аналог scalameta для котлина уже есть?

Нет, для этого же нужно компилятор шатать

Нет, для этого же нужно компилятор шатать

Найс тема для стажировки на лето или диплома, btw

Найс тема для стажировки на лето или диплома, btw

Вы что, хотите чтобы как на Укр^W как в скале?

Вы что, хотите чтобы как на Укр^W как в скале?

Но мы же можем анексиров^W сделать правильные макросы!

В dotty же нет макросов? Их деликатно перенесли в расширения, а оттуда еще подальше?

В dotty же нет макросов? Их деликатно перенесли в расширения, а оттуда еще подальше?

Есть blackbox macro + inline Inline будет более предсказуемой версией whitebox

Подскажите, плиз: что за * в синтаксисе? Типа *args

Подскажите, плиз: что за * в синтаксисе? Типа *args

spread operator

arrayOf(a, b, c) == arrayOf(*arrayOf(a, b), c)