# OverloadedRecordDot and Lenses

**URL:** <https://discourse.haskell.org/t/overloadedrecorddot-and-lenses/5651>\
**Category:** Learn\
**Created:** [January 24, 2023, 8:36am UTC](https://discourse.haskell.org/t/overloadedrecorddot-and-lenses/5651 "2023-01-24T08:36:24Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![olivier.revollat](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/olivier.revollat/32/2922_2.png) [@olivier.revollat](https://discourse.haskell.org/u/olivier.revollat)\
**Post date:** [January 24, 2023, 8:36am UTC](https://discourse.haskell.org/t/overloadedrecorddot-and-lenses/5651/1 "2023-01-24T08:36:24Z")

</div>

Hello, does OverloadedRecordDot (GHC extension since 9.2) replace lenses concepts or are they meant to be use together ?

---

<div class="post-metadata">

**Author:** ![Kleidukos](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/kleidukos/32/1213_2.png) [@Kleidukos](https://discourse.haskell.org/u/Kleidukos)\
**Post date:** [January 24, 2023, 9:47am UTC](https://discourse.haskell.org/t/overloadedrecorddot-and-lenses/5651/2 "2023-01-24T09:47:17Z")

</div>

At work we use them together (with the [`optics`](https://flora.pm/packages/@hackage/optics-core) library):

- Dot accessors for “simple” access (record.subrecord.field)
- Optics for more complex access (`preview` especially). One usecase is the implementation of a PATCH endpoint where the values of the resource in database are substituted by the fields present in the payload, and left alone if the payload value is set to `Nothing`.
- Optics for record updates

---

<div class="post-metadata">

**Author:** ![mixphix](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mixphix/32/5629_2.png) [@mixphix](https://discourse.haskell.org/u/mixphix)\
**Post date:** [January 24, 2023, 2:49pm UTC](https://discourse.haskell.org/t/overloadedrecorddot-and-lenses/5651/3 "2023-01-24T14:49:36Z")

</div>

I have also recently started using `OverloadedRecordDot` at work, where we also use `lens`. My experience has been quite similar to the above:

- Dot accessors are extremely comfortable and work well with `(<&>)` — but sensitive to autoformatting breaking code if pasted into a module without `{-# LANGUAGE OverloadedRecordDot #-}`
- Record updates are easier with `lens` functions, especially `(?~)` and `(%~)`. We have helper functions for preadjusting settings with an argument `[settings -> settings]`; we fill this list with things like `fields <>~ [x, y, z]` and `name ?~ value`.

We haven’t yet run into naming issues between field accessors and lenses, though it would be nice to be able to use the same name in both places: `datatype.field` and `datatype ^. field`.