Comments 12
Привет! Спасибо за перевод.
Я так понимаю куски кода специально не менялись, чтобы сохранить авторской стиль, но мне кажется для образовательного проекта будет лучше отформатировать их согласно Official Kotlin Styleguide в лучшей IDE!
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
Тяжеловато читать переводы и этот не исключение. В процессе совершенно теряется замысел доносимого и предложения строятся по каким то неведомым правилам. Наверное получиться лучше, если переводчик осознав что написано в оригинальной статье, заново напишет своими словами, не пытаясь придерживаться оригинала.
Прочитал про неработающих множественных получателей, захотелось попробовать сделать это на текущих возможностях языка:
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.", то у программиста появилось бы больше контроля над происходящим: дать получателю имя и вызывать его методы явно или оставить "без имени".
В чём замысел-то был?
В том что до P.S.?
Так как сейчас в котлине получатель может быть только один, я попробовал собрать контекст из нескольких получателей в один объект. К сожалению, из-за ограничений языка красивого решения не получилось, но в каком-то виде оно может работать.
Введение в контекстно-ориентированное программирование на Kotlin