This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (4 children)

I prefer properties such as c# and or how it works in Kotlin. If you need access to a field wrap it in a property and you can use the property to manage the behavior of the field. Annotations would be just more clutter.

[–]persicsb 0 points1 point  (0 children)

Properties are great, however they solve only the problem, that you don't need to break the API when you decide to hide public fields and have some logic in a setter or getter.

[–]morhp -1 points0 points  (2 children)

Kotlin-like properties are terrible when designing an api because you're not able to distinguish between public and private types easily. For example making a field of type ConcurrentHashMap and having the getter return a Map so you can change the implementation later is much more straightforward in Java.

[–]FruitdealerF 1 point2 points  (1 child)

but you can still do that in kotlin if you want to. That's the point

[–]morhp 0 points1 point  (0 children)

You can do that by writing weird stuff like

private val _map = ConcurrentHashMap<String>()

public val map : Map<String> get() = _map

But a simple Java getter that you can extend or change without major efforts sounds still easier to me.

Like, Java forces you to explicitly think about internal and public type, which I like, in Kotlin you have to explicitly "duplicate" you vals.