Введение в контекстно-ориентированное программирование на Kotlin

[UbuRus]

Привет! Спасибо за перевод.
Я так понимаю куски кода специально не менялись, чтобы сохранить авторской стиль, но мне кажется для образовательного проекта будет лучше отформатировать их согласно Official Kotlin Styleguide в лучшей IDE!

[darksnake]

А я чего-то не вижу, где что не по styleguide. Можно тыкнуть?

[UbuRus]

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

Форматирование лямб и методов, должен быть пробел перед {

suspend fun CoroutineScope.doSomeWork(){}

GlobalScope.launch{

launch{

override val root = gridPane{

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

Бинарный оператор, не хватает пробелов:

(n1 + n2)/2

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

Лишний пробел:

operator fun Number.plus(other: Number)_: Number

[darksnake]

Согласен. Но за пробелами следить — это как-то слишком напряжно. Я как правило код для статей и презентаций делаю в play.kotlinlang.org или в VSCode, чтобы не плодить проекты в идее. В обоих случаях поддержка код-стайла ограниченная.

[audiserg]

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

[darksnake]

Оригинал писал не native speaker. Так что там уже не супер.

[pk1]

Вы с одной стороны правы, и вероятно получится лучше, но речь идет о существенно разных по трудозатратам задачах — переводить или же писать самому.

[lgorSL]

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

interface IA
interface IB
class A : IA
class B : IB

fun myPrint(a: IA, b: IB) = println("ok!")
fun Pair<IA, IB>.myPrint() = myPrint(first, second)
fun <A, B, R> A.productWith(b: B, block: Pair<A, B>.() -> R): R  = Pair(this, b).block()

fun main(args: Array<String>) {
    with(A()) {
        productWith(B()) {
            myPrint()
        }
    }
}

Из недостатков — важен порядок А и B. Я попытался использовать более хитрые типы (в java это A & B), в котлине пишется через where:

fun <T> T.myPrint2() where T : IA, T : IB = myPrint(this as IA, this as IB)

Но эта фича как-то очень ограниченно реализована и следующий код не скомпилируется:

fun <A, B, T, R> A.betterWith(b: B, block: T.() -> R): R where T : A, T : B {}

Якобы в обобщённом случае нельзя сразу два ограничения на тип написать :(

P.S. А вообще, кмк, для множественных получателей (да и для одного тоже) не надо какой-то новый синтаксис придумывать. Варианты как в go/dotty вполне понятно выглядят и хорошо читаются. Можно было бы по аналогии сделать:

fun (this: T).doSmth() ...
или fun (a: A, b: B).doInContext(arg: Arg) ...
или даже так: fun (a: Int).+(b: Int) ...

Кроме того, если договориться, что появление в скоупе переменной с именем this разрешает вызывать её методы без явного указания "this.", то у программиста появилось бы больше контроля над происходящим: дать получателю имя и вызывать его методы явно или оставить "без имени".

[zagayevskiy]

В чём замысел-то был?

[lgorSL]

В том что до P.S.?
Так как сейчас в котлине получатель может быть только один, я попробовал собрать контекст из нескольких получателей в один объект. К сожалению, из-за ограничений языка красивого решения не получилось, но в каком-то виде оно может работать.

[zagayevskiy]

Не понял, КАК оно должно работать по замыслу. Ну да, экстеншн к паре. Ну да, пара создаётся. А замысел-то в чём…
Множественные ресиверы работают не так.

[darksnake]

Это один из вариантов. Но к сожалению он не особо осмысленный, поскольку все равно не будет ссылки на элемент, как на `this`. Проще передать параметрами. Кроме того, из за генерации пар может быть существенная потеря в перформансе на аллокацию лишнего объекта.