# Point Operator to access field

**URL:** <https://discuss.kotlinlang.org/t/point-operator-to-access-field/12054>\
**Category:** Language Design\
**Created:** [March 21, 2019, 11:15am UTC](https://discuss.kotlinlang.org/t/point-operator-to-access-field/12054 "2019-03-21T11:15:10Z")\
**Posts on this page:** 3\
**Page:** 2

<div class="post-metadata">

**Author:** ![darksnake](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/darksnake/32/2479_2.png) [@darksnake](https://discuss.kotlinlang.org/u/darksnake)\
**Post date:** [March 27, 2019, 10:20am UTC](https://discuss.kotlinlang.org/t/point-operator-to-access-field/12054/21 "2019-03-27T10:20:37Z")

</div>

The stdlib developers already [though about it](https://kotlinlang.org/docs/reference/delegated-properties.html#storing-properties-in-a-map).

---

<div class="post-metadata">

**Author:** ![abond](https://avatars.discourse-cdn.com/v4/letter/a/8c91f0/32.png) [@abond](https://discuss.kotlinlang.org/u/abond)\
**Post date:** [March 27, 2019, 10:40am UTC](https://discuss.kotlinlang.org/t/point-operator-to-access-field/12054/22 "2019-03-27T10:40:01Z")

</div>

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

```

---

<div class="post-metadata">

**Author:** ![gidds](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/gidds/32/10865_2.png) [@gidds](https://discuss.kotlinlang.org/u/gidds)\
**Post date:** [March 27, 2019, 2:51pm UTC](https://discuss.kotlinlang.org/t/point-operator-to-access-field/12054/23 "2019-03-27T14:51:19Z")

</div>

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!

[Previous page](https://discuss.kotlinlang.org/t/point-operator-to-access-field/12054.md?page=1)