PE
this@Int*
а почему int если первым идет view? как это вычисляется?
Size: a a a
2020 October 13
PE
как это можно догадаться то что this это Int а не View?
SB
я не очень понимаю а какое тогда решение тут привносит декоратор? Декоратор это функция которая принимает функцию и оборачивает ее неким образом, или я что-то концептуальное упускаю?
PE
ладно там типа this@Int * this@View ...
с#
а почему int если первым идет view? как это вычисляется?
эм
with(view) View@ {
with(int) Int@ {
println(this@Int * resources ...)
}
}
with(view) View@ {
with(int) Int@ {
println(this@Int * resources ...)
}
}
PE
эм
with(view) View@ {
with(int) Int@ {
println(this@Int * resources ...)
}
}
with(view) View@ {
with(int) Int@ {
println(this@Int * resources ...)
}
}
да, если в этом виде мы понимаем что происходит, то выше код не очевиден просто
с#
да, если в этом виде мы понимаем что происходит, то выше код не очевиден просто
почему? запретить просто к this обращаться
PE
все таки это не правильный дизайн имхо, с точки зрения программиста
VP
я не очень понимаю а какое тогда решение тут привносит декоратор? Декоратор это функция которая принимает функцию и оборачивает ее неким образом, или я что-то концептуальное упускаю?
А вы доклад-то смотрели?)
Декоратор может накидывать дополнительных ресиверов от себя. Простейший декоратор только это и делает.
Декоратор может накидывать дополнительных ресиверов от себя. Простейший декоратор только это и делает.
с#
только через named-this
PE
почему? запретить просто к this обращаться
прсото надо заставить маркировать то к чему обращаешься
PE
и тогда все чики пуки, да
VP
Обсуждать синтаксис сейчас смысла не вижу
AM
да, если в этом виде мы понимаем что происходит, то выше код не очевиден просто
Всё так. А в случае декораторов вроде хорошо понятно, что во что nested, и в каком порядке мог бы быть обход this-ов. И то по-моему шла речь, что unqualified this, вероятно, будет запрещён.
PE
тогда все нормас, если будет запрещен
SB
А вы доклад-то смотрели?)
Декоратор может накидывать дополнительных ресиверов от себя. Простейший декоратор только это и делает.
Декоратор может накидывать дополнительных ресиверов от себя. Простейший декоратор только это и делает.
смотрел, но не понимаю как например это использовать в интерфейсах, где хочется потребовать реализации такого экстеншна
OY
А вы доклад-то смотрели?)
Декоратор может накидывать дополнительных ресиверов от себя. Простейший декоратор только это и делает.
Декоратор может накидывать дополнительных ресиверов от себя. Простейший декоратор только это и делает.
а теперь кстати задумался и стало интересно
сейчас, ф-ия with:
как тогда она будет в декораторах выглядить, чтобы писать при использовании только один тайп параметр
сейчас, ф-ия with:
inline fun <T, R> with(receiver: T, block: T.() -> R): R
то есть у неё 2 тайп параметракак тогда она будет в декораторах выглядить, чтобы писать при использовании только один тайп параметр
VP
смотрел, но не понимаю как например это использовать в интерфейсах, где хочется потребовать реализации такого экстеншна
Вот с интерфейсами и переопределением это всё хз как может работать. Возможно, никак.
SB
или можно будет объявить
interface A {
@with<C>
fun B.foo()
}АО
а на ютреке нельзя минус задаче поставить?