Whoa, Android Support Library team interested by K...

# android

[gildor]

Whoa,
Android Support Library team interested by Kotlin language feature 👏
https://youtrack.jetbrains.com/issue/KT-4075#comment=27-2588411

Something interesting coming 🤔

[lovis]

wow that's a pretty bad idea, imho 😅

[gildor]

Why?

[gildor]

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

[bdawg.io]

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

[gildor]

Why is it weird?
Very convenient in many cases and have exactly the same behaviour as any function overloading.

[bdawg.io]

Whatever happens, I think the property getter should remain as the property type and then setter overloads specified in the parameter type

var foo: A = ...
    set(b: B) { ... }

[gildor]

Private getters is an another proposal that probably should be implemented

[gildor]

For example C# has private getters

[gildor]

You can have exactly the same code now with functions:

fun getFoo(): A
fun setFoo(b: B)

[gildor]

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

[gildor]

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

[lovis]

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)

[lovis]

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...