implement mutation guard

[Ichthyostega]

An idea from ongoing development, noted for later...

We are moving towards an architecture, where direct manipulation of session data is no longer allowed; any changes have to pass through a logging mechanism and record an Action.

Thus it seemed conceivable to use diagnostic facility allowing to detect mutations, which bypass the canonical access path.

[Ichthyostega]

how is this going to work? seems relevant when discussing thread safety in the context of the GUI event thread.

In 2010, I left an implementation sketch on the ​session interface page of the TiddlyWiki

• change the MObjectRef to return only const references
• have a mutation enabled subclass
• this opens a wormhole to check for a mutation token
• someone up the callstack must have placed such a mutation allowance token into thread local storage
• the proc command dispatcher does this by default

thus, given a conventional threading environment, this guard mechanism would work transparently for the user. It would not work if we ever decide to invoke session mutations from rendering jobs (which perform in a thread pool based, actor-like environment).

[Ichthyostega]

This approach looks questionable.
In a low-level language, direct access to data can never be prevented, and any solution would have to rely on further infrastructure for instrumentation, which is either heavyweight, or leaves lots of loopholes to bypass.

Thus: rather keep the architecture straight and wait if we have to face actual problems of this kind

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin