The stdlib developers already though about it.
I know about this feature.
Maybe I’m wrong, but it feels too heavyweight to create new class just to replace this:
map["propName"]
or this:
map[propNameConst]
with this:
map.propName
1 Like
I agree with abond.
Kotlin is a static, strongly-typed language. Dynamic languages have their place, but Kotlin isn’t one of them.
If you want a set of properties that are known at compile-time, fully type-checked, null-checked, scoped, initialised, accessible to reflection, overridable, known to your IDE, documented, annotated, &c, then you can use standard properties. Or if you want a set of properties that are known only at runtime, then you can use a map and forego all those other benefits.
Trying to force one to look like the other for a very minor notational convenience seems utterly pointless to me. It would risk an awful lot of confusion (e.g developers not realising the lack of checking or performance impact) — and Kotlin’s map notation is hardly verbose!
3 Likes