Better way to control the wrapper class

[thorwhalen]

The use of Store.wrap to wrap stores led to some design difficulties when wrapping objects that have methods, other than those of MutuableMapping that use (as inputs or outputs) keys or values.

This happened in the context of our work on Mapping Views and mongodol.

@valentin-feron; you can add more detail if you want.

In order to repair this, a wrapper argument was added to kv_wraps, used like this:

wrapper = wrapper or Store
...
return wrapper.wrap(store, class_trans=class_trans)

The problem here is that this method obliges us to add this wrapper argument in all our store wrappers -- or at least those who use Store.wrap.

One way to mitigate this would be to make the store_decorator add that argument (and it's handling).

Another way would be to not include this wrapper argument in the wrapping functions at all, but instead, have them look for
a hook in the object they're wrapping. Which would result in the above code being replaced by:

wrapper = getattr(store, 'wrap') or Store.wrap
...
return wrapper(store, class_trans=class_trans)

┆Issue is synchronized with this Asana task by Unito

[thorwhalen]

Triage (2026-07): priority: medium, Wave 1 — the Store.wrap family; do alongside #6. This is part of the same wrapping/signature machinery that underlies #9/#12/#18. The store_decorator/Store.wrap mechanics are documented in misc/docs/dol_architecture_map.md §5. Recommend sequencing after the #12 marker decision so the wrapper-control redesign builds on a settled convention.