SB
Дико извиняюсь за встревание, а с интерфейсами глухо будет? Просить реализовать условный
interface A {
@with<C>
fun B.foo()
}Size: a a a
2020 October 13
RE
Почему глухо. Всюду будет работать. Там всё одинаковая механика
AN
Ну будет, конечно, влиять, порядок, но не очень понятно в каких реальных кейса это будет кому-либо важно.
Сейчас это уже важно. Если есть эктеншен ресивер и мембер ресивер, то можно писать
with(a){
b.doSomething()
}
но обратно работать не будет, надо писать:
with(b){
with(a){ doSomething}
}
with(a){
b.doSomething()
}
но обратно работать не будет, надо писать:
with(b){
with(a){ doSomething}
}
OY
а теперь кстати задумался и стало интересно
сейчас, ф-ия with:
как тогда она будет в декораторах выглядить, чтобы писать при использовании только один тайп параметр
сейчас, ф-ия with:
inline fun <T, R> with(receiver: T, block: T.() -> R): R
то есть у неё 2 тайп параметракак тогда она будет в декораторах выглядить, чтобы писать при использовании только один тайп параметр
@relizarov а как примерно будет выглядеть этот with декоратор, если ему нужны 2 тайп параметра на вход, и 1 на использование
Я что-то не совсем понимаю
Я что-то не совсем понимаю
RE
Дополнительные ресиверы вообще через синтаксис "b.foo()" нельзя будет передать. Только через
with. А там поиск ближайшего подходящего ресивера по типуAN
Там ключевой камень приткновения при обсуждении KEEP-176 был как раз в том, влияет ли порядок при байндинге функций. Мне нравится вариант, когда порядок не влияет
RE
При поиске подходящего ресивера не важно как они объявлены в вызывающей функции, но важно в каком порядке в скоупе. А вот тонкости типа "а что если в скоуп несколько ресиверов сразу занесли, то есть ли порядок" будем обсуждать когда реальные примеры будут.
AN
При поиске подходящего ресивера не важно как они объявлены в вызывающей функции, но важно в каком порядке в скоупе. А вот тонкости типа "а что если в скоуп несколько ресиверов сразу занесли, то есть ли порядок" будем обсуждать когда реальные примеры будут.
Главный вопрос в том будет ли @with<A,B> fun foo. Считаться той же функцией, что и @with<B,A>.
AN
При поиске подходящего ресивера не важно как они объявлены в вызывающей функции, но важно в каком порядке в скоупе. А вот тонкости типа "а что если в скоуп несколько ресиверов сразу занесли, то есть ли порядок" будем обсуждать когда реальные примеры будут.
Меня интересует, как автокомплит будет искать кандидатов.
SB
Главный вопрос в том будет ли @with<A,B> fun foo. Считаться той же функцией, что и @with<B,A>.
кажется что это будет зависеть от
@with<A>
@with<B>
или это
@with<B>
@with<A>
и именно поэтому не будет такого шортката для дабл ресивера
@with<A>
@with<B>
или это
@with<B>
@with<A>
и именно поэтому не будет такого шортката для дабл ресивера
AN
кажется что это будет зависеть от
@with<A>
@with<B>
или это
@with<B>
@with<A>
и именно поэтому не будет такого шортката для дабл ресивера
@with<A>
@with<B>
или это
@with<B>
@with<A>
и именно поэтому не будет такого шортката для дабл ресивера
А какая разница. Если это делегаты, то не проблема два в один завернуть
AN
При поиске подходящего ресивера не важно как они объявлены в вызывающей функции, но важно в каком порядке в скоупе. А вот тонкости типа "а что если в скоуп несколько ресиверов сразу занесли, то есть ли порядок" будем обсуждать когда реальные примеры будут.
Я сейчас посмотрел вот сюда: https://github.com/Kotlin/KEEP/pull/176#issuecomment-460147227. То, что вы говорите похоже в точности следует моему пропозалу по разрешению и оно таки ломает в корнер кейсах старый вариант (https://github.com/Kotlin/KEEP/pull/176#issuecomment-578172687). Впрочем, если действительно сделать правила разрешения для мембер экстеншенов отдельно, а для декораторов отдельно, тогда все наверное будет правильно, но будут конфликты этих правил.
QH
Я кстати починил тормоза с синком, там в файерволе проблемы были
а, ну а у меня просто идея тормозит на каждый чих
D
а, ну а у меня просто идея тормозит на каждый чих
Винда?
EU
Всем привет. Подскажите. Пробую использовать котлин по jsr223 (Java Script API) как встроенный скриптовый движок, но при попытке запустить программу в идее, программа падает с ошибкой WARN: Unable to load JNA library (OS: Mac OS X 10.15.7)
java.lang.NoClassDefFoundError: com/sun/jna/Native.
Версия котлина 1.4.10, версия идеи 2020.2, версия java - 11, ссылка на стек трейс https://pastebin.com/L1yT3qZU
java.lang.NoClassDefFoundError: com/sun/jna/Native.
Версия котлина 1.4.10, версия идеи 2020.2, версия java - 11, ссылка на стек трейс https://pastebin.com/L1yT3qZU
AN
Всем привет. Подскажите. Пробую использовать котлин по jsr223 (Java Script API) как встроенный скриптовый движок, но при попытке запустить программу в идее, программа падает с ошибкой WARN: Unable to load JNA library (OS: Mac OS X 10.15.7)
java.lang.NoClassDefFoundError: com/sun/jna/Native.
Версия котлина 1.4.10, версия идеи 2020.2, версия java - 11, ссылка на стек трейс https://pastebin.com/L1yT3qZU
java.lang.NoClassDefFoundError: com/sun/jna/Native.
Версия котлина 1.4.10, версия идеи 2020.2, версия java - 11, ссылка на стек трейс https://pastebin.com/L1yT3qZU
А откуда у вас jna вообще?
EU
прикрепил стек трейс
AN
прикрепил стек трейс
404
EU
А откуда у вас jna вообще?
понятия не имею к сожалению
EU
минуту