companion object { val app by lazy { this@Application } }

Хоте нет))

Хоте нет))

Я было подумал, что от меня скрыли часть языка ?

А что тут такого?

Разве что из компаниона не обратьться к зис

Разве что из компаниона не обратьться к зис

ты обратишься к this компаньена, а не Application

Там сабака стоит

Но тут это не спасет

Вот именно что скомпилируется только val app by lazy { this@Companion }

В общем окей, что бы со стороны оно виделось как val - заюзаю 2 поля

Есть мысль сделать свой делегат в котором можно будет сэтить контекст

object AppInstanceHolder { getValue... init(app:App) }

Но на деле ничем от двух полей не отличается кроме неявности лишней

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

Вообще читал в заметкам к одному из пререлизов котлина что есть планы по lateinit val, но это не будет лейтинит вал (если ничего не путаю)

а вот кто-нибудь знает, почему нельзя вот так написать? var clientId: String override get set

я имею ввиду, если я имплементирую джавовский интерфейс с методом String getClientId(), то было бы здорово иметь возможность пропертю обявить так, чтобы геттер оверрайдил этот метод

а вот кто-нибудь знает, почему нельзя вот так написать? var clientId: String override get set

а разве у get есть возможность поставить override?

а разве у get есть возможность поставить override?

нету, в том и проблема

т.е. вроде очевидная фигня, но не работает

я имею ввиду, если я имплементирую джавовский интерфейс с методом String getClientId(), то было бы здорово иметь возможность пропертю обявить так, чтобы геттер оверрайдил этот метод

у тебя же будет обязательным этот метод, причем он же будет независим от проперти

а разве у get есть возможность поставить override?

По-идее - должна быть, в доках что-то такое мутно написано

?

у тебя же будет обязательным этот метод, причем он же будет независим от проперти

не понял

По-идее - должна быть, в доках что-то такое мутно написано

не видел, можешь ссылочку дать, если знаешь где?

Вот про простые аксессоры что-то написано https://discuss.kotlinlang.org/t/custom-getter-setter-for-properties-created-by-type-params/46/5

не понял

ну в котлин просто методы и get/set для проперти имеют разную природу, соответственно они не могут заменять друг друга, и при реализации интерфейса его метод должен был переопределен независимо от пропертей

не видел, можешь ссылочку дать, если знаешь где?

Override java getters and setters в youtrack поищи

https://kotlinlang.org/docs/reference/classes.html#overriding-properties

А это доки

https://kotlinlang.org/docs/reference/classes.html#overriding-properties

смысл в том, что в классе есть проперти clientId и этот класс реализует интерфейс с методом String getClientId(), и хочется, чтобы геттер у проперти переопределял метод интерфейса

https://youtrack.jetbrains.com/issue/KT-6653

смысл в том, что в классе есть проперти clientId и этот класс реализует интерфейс с методом String getClientId(), и хочется, чтобы геттер у проперти переопределял метод интерфейса

А, это. Тоже столкнулся с таким, по итогу просто забил и сделал propertyName() аксессоры в интерфейсах/суперклассах

Интересно, что Андрей Бреслав в этом ишью не дает внятного ответа про то какими собственно рисками чревата такая функциональность

Интересно, что Андрей Бреслав в этом ишью не дает внятного ответа про то какими собственно рисками чревата такая функциональность

А если ты в классе A реализовал этот метод интерфейса как геттер, унаследовал класс B от A, а затем решил переопределить метод интерфейса?

ну да, он так и пишет, что работать это может только так: a function can override a property, and a property can override a function

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

Ну а вообще, как я писал выше, "методы и get/set для проперти имеют разную природу", тут в принципе такой подход использовать нелогично

А если ты в классе A реализовал этот метод интерфейса как геттер, унаследовал класс B от A, а затем решил переопределить метод интерфейса?

так а в чем собственно проблема-то?

так а в чем собственно проблема-то?

в том, что у тебя все еще есть проперти с этим геттером, а геттер ты по факту переопределил

ну и ты как бы переопределяешь метод интерфейса, даже не думая, что это еще и геттер у проперти

еще раз говорю, "методы и get/set для проперти имеют разную природу", поэтому они используются и воспринимаются (по умолчанию) как разные вещи, и мешать их друг с другом лично я бы не стал

Ну а вообще, как я писал выше, "методы и get/set для проперти имеют разную природу", тут в принципе такой подход использовать нелогично

так можно было бы говорить, если бы фичей котлина не была совместимость с джавой 100%, а так получается, что не смотря на то, что проперти в сущности своей это пара акцессоров при любом раскладе, получается, что для поддержки этой функциональности нужно костылить

еще раз говорю, "методы и get/set для проперти имеют разную природу", поэтому они используются и воспринимаются (по умолчанию) как разные вещи, и мешать их друг с другом лично я бы не стал

опять же это можно было бы сделать только как совместимость к джавой вроде как САМ сделан только для джава-классов -- просто для того, чтобы иметь совместимость пропертей и джава-бинов

ведь в других местах они с ними совместимы

опять же это можно было бы сделать только как совместимость к джавой вроде как САМ сделан только для джава-классов -- просто для того, чтобы иметь совместимость пропертей и джава-бинов

ну в котлине же, в отличие от джавы, нет возможности в String писать null, также нет возможности и аксессор использовать как обычный метод

то, что в джаве что-то можно, еще не значит, что это хорошо

ну в котлине же, в отличие от джавы, нет возможности в String писать null, также нет возможности и аксессор использовать как обычный метод

конечно в котлине есть возможность писать в String null для этого достаточно его пометить ?

иначе это был бы треш

конечно в котлине есть возможность писать в String null для этого достаточно его пометить ?

это будет уже другой тип

то, что в джаве что-то можно, еще не значит, что это хорошо

если в джаве что-то можно, значит скорее всего это что-то используется и с этим нужна какая-то совместимость

это будет уже другой тип

это будет как раз джавовский String, так что если говорить строго то в котлине можно писать null в джавовый String

ну а вообще, Бреслав сколько уже раз говорил, что в котлине "все explicit", взаимозаменяемость геттера и наследуемого от интерфейса метода не очень explicit, когда нужно этот метод переопределить

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

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

вот что важнее - хороший, понятный explicit язык, или совместимость с джавой во всем?

ну а вообще, Бреслав сколько уже раз говорил, что в котлине "все explicit", взаимозаменяемость геттера и наследуемого от интерфейса метода не очень explicit, когда нужно этот метод переопределить

explicit в данном случае это явное обозначение его как override, остальное тоже можно сделать явным имея желание, аннотацию специальную как это сделано для некоторых других моментов

explicit в данном случае это явное обозначение его как override, остальное тоже можно сделать явным имея желание, аннотацию специальную как это сделано для некоторых других моментов

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

вот что важнее - хороший, понятный explicit язык, или совместимость с джавой во всем?

я просто не до конца понимаю, почему нужно выбирать, не вижу для этого причин. Понимаю, что они очевидно есть, если Бреслав считает, что реализация затруднительна, просто хотелось бы услышать эти сообрежения

я просто не до конца понимаю, почему нужно выбирать, не вижу для этого причин. Понимаю, что они очевидно есть, если Бреслав считает, что реализация затруднительна, просто хотелось бы услышать эти сообрежения

как по мне, описанный мной выше пример вполне показывает, что такая фича неоднозначна, и решение по добавлению ее в язык тоже неоднозначно

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

ну это не повод, если ты не видишь что метод переопределен, то не важно проперти это или нет, ты попадаешь в ситуацию, когда ты не понимаешь, почему у тебя не такое поведение, которое ты ожидаешь

однако переопределение как таковое существует

ну это не повод, если ты не видишь что метод переопределен, то не важно проперти это или нет, ты попадаешь в ситуацию, когда ты не понимаешь, почему у тебя не такое поведение, которое ты ожидаешь

Кстати, в джаве аксессоры являются методами и рассматриваются как методы, в котлине же аксессоры методами не являются (и как методы не рассматриваются), поэтому переопределять аксессор с помощью метода и метод с помощью аксессора нелогично как минимум. Правда, я уже повторяюсь

в котлине это тоже методы, просто привязанные к проперти, ты недвусмысленно задаешь их при определении проперти

в котлине это тоже методы, просто привязанные к проперти, ты недвусмысленно задаешь их при определении проперти

Ну тогда скажу так: Как-то нелогично, что метод, не привязанный к проперти (метод интерфейса), будет менять эту проперти

И вообще, Бреслав (или даже Жемеров) не раз говорил, что (примерно) если какая-то фича несет в себе какие-то неоднозначности, то они (разрабы котлина) несколько раз подумают, прежде чем вводить эту фичу в язык

опять же я еще раз говорю, что это могло бы быть специальной аннотацией вроде @JvmAccessorOverride или типа того, которая бы давала возможность переопределить джавовский аксессор. И еще раз: я понимаю, что эта фича которая требует продумывания, просто хотелось услышать мотивацию, почему за это не берутся и пока я услашал только одну на мой взгляд важную причину, это что в языке пришлось бы делать возможность переопределять проперти-акцессор методом, потому что иначе не все кейзы были бы покрыты, но возможно эти кейзы лучше было бы запретить, чем запретить оверрайд как таковой

ERROR: S client not available

опять же я еще раз говорю, что это могло бы быть специальной аннотацией вроде @JvmAccessorOverride или типа того, которая бы давала возможность переопределить джавовский аксессор. И еще раз: я понимаю, что эта фича которая требует продумывания, просто хотелось услышать мотивацию, почему за это не берутся и пока я услашал только одну на мой взгляд важную причину, это что в языке пришлось бы делать возможность переопределять проперти-акцессор методом, потому что иначе не все кейзы были бы покрыты, но возможно эти кейзы лучше было бы запретить, чем запретить оверрайд как таковой

Ну если так, то вопрос с моей стороны: а кто-то разрабам котлина предлагал сделать эту фичу в виде аннотации? (просто если нет, то вполне возможно, что фича эта рассматривалась только именно как постоянная фича языка, а не как доп средство для интероперабилити типа @JvmStatic)

Ну если так, то вопрос с моей стороны: а кто-то разрабам котлина предлагал сделать эту фичу в виде аннотации? (просто если нет, то вполне возможно, что фича эта рассматривалась только именно как постоянная фича языка, а не как доп средство для интероперабилити типа @JvmStatic)

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

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

Ну свои мысли по поводу внедрения этой фичи как фичи языка я высказал, а по поводу внедрения как фичи совместимости (то бишь в виде аннотации) - ничего против не имею, скорее даже соглашусь, что такая возможность должна быть

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

Кто-нибудь, скажите мне, есть вариант обойти ограничение на то, что в функцию нельзя передавать var переменную?

чо?

почему нельзя?

Вот так. .-. Говорит "к этому моменту эта переменная могла быть изменена, поэтому иди н***й".

может пример кода?

наверное речь о nullable var, а функция принимает nonnull

наверное типы разные

В том-то и дело, что проверка на null проходит преждевременно.

может пример кода?

Минуту.

можно, да, если по-простому, то вот так: fun test() { var a:Int? = 10 a?.let { va -> call(va) } } fun call(a: Int) { }

a!!

:)

или так вот: fun test() { var a:Int? = 10 val va = a if (va != null) { call(va) } } fun call(a: Int) { }

A, я забыл там дописать в основном add

Но не важно

типы не совпадают

передаешь Int? в аргумент с Int

Проверяя, не является ли null

для var не работает смарткаст

И что делать?

поставь !!.

Окей

data class A(var prop: Int? = null) fun test() { val a = A() a.prop.let { prop -> if (prop != null) { call(prop) } else { somethingElse() } } } fun call(a: Int) { }

поставь !!.

Спасибо

ой

но это вариант для плохих парней :D

А для "хороших"?