https://kotlinlang.org logo
#android
Title
# android
g

gildor

12/07/2017, 2:56 AM
Whoa, Android Support Library team interested by Kotlin language feature 👏 https://youtrack.jetbrains.com/issue/KT-4075#comment=27-2588411 Something interesting coming 🤔
🤔 3
l

lovis

12/07/2017, 8:12 AM
wow that's a pretty bad idea, imho 😅
g

gildor

12/07/2017, 8:13 AM
Why?
It’s exatly the same thing that you can do now with any method in Kotlin or Java. And property setter is just a special case of method that provides different invocation syntax
b

bdawg.io

12/07/2017, 9:44 AM
Considering that properties are just variables that sometimes have getters and setters created during compilation, it feels weird to assign
=
a property to multiple types
👍 1
g

gildor

12/07/2017, 9:49 AM
Why is it weird? Very convenient in many cases and have exactly the same behaviour as any function overloading.
b

bdawg.io

12/07/2017, 9:50 AM
Whatever happens, I think the property getter should remain as the property type and then setter overloads specified in the parameter type
Copy code
var foo: A = ...
    set(b: B) { ... }
g

gildor

12/07/2017, 9:52 AM
Private getters is an another proposal that probably should be implemented
For example C# has private getters
You can have exactly the same code now with functions:
Copy code
fun getFoo(): A
fun setFoo(b: B)
but properties syntax better and this feature allow you to evolve your api. Imagine you have property
var foo: A
, but now you want to have also B setter (for case something like
A(b)
), so to cover such case you must add
fun setFoo(b: B)
or replace property with methods
first option looks ugly and doesn’t work well with DSL, second option requires to refactor all the
foo
usages and again, you cannot use property syntax
l

lovis

12/07/2017, 10:55 AM
IMHO a feature like this has great potential to introduce an unreadable mess into codebases. ¯\_(ツ)_/¯ also it goes against the concept of a property. You should not override
set
at all, but give meaningful names to functions . I'd always prefer an extension function for this:
myThing.foo = bar.asFoo()
(or something like that, and it also works well with dsls)
There are also some cases where you may want to accept a null value on a non-nullable property and convert the null into some default value for the getter
this comment on this is especially freaking me out...
💯 1
3 Views