-
-
Notifications
You must be signed in to change notification settings - Fork 108
Description
Checklist
- I read the documentation at https://chimney.readthedocs.io/ and checked that the functionality doesn't exist
- I checked the https://github.com/scalalandio/chimney/issues and haven't found the feature already requested reported
- I confirmed that the request is not related to functionality that was deprecated: lifted transformers (
TransformerF
s) orunsafeOption
flags - I believe that this is actual feature request, rather than a question how to use existing features
Describe the desired behavior
patch
to support mutable classes. To simplify code like:
def loadPulse(s: PulseSnapshot, p: State#PulseRegisters): LoadStore.Result = {
p.enable = s.enable
p.counter = s.counter
p.dutyCycle = s.dutyCycle
p.sweepEnable = s.sweepEnable
p.sweepPeriodLoad = s.sweepPeriodLoad
p.sweepReload = s.sweepReload
p.sweepTimer = s.sweepTimer
p.sweepNegate = s.sweepNegate
p.sweepShift = s.sweepShift
p.timer = s.timer
p.timerLoad = s.timerLoad
p.sequencePoint = s.sequencePoint
loadEnvelope(s.envelope, p.envelope)
}
def storePulse(p: State#PulseRegisters): PulseSnapshot =
p.into[PulseSnapshot]
.enableInheritedAccessors
.withFieldComputed(_.envelope, s => storeEnvelope(s.envelope))
.transform
Use case example
For general amusement and other reasons I use large mutable classes in an NES emulator for system state.
EG:
Yes public vars
and all. Good times!
A classic feature of emulators are "save states". Which, as you might guess: Persists the state of the system and enables restoring the state of the system.
The physical model of this save is defined separate from the runtime State. No problem:
- Bunch of
case class
es for the persistent model - chimney to go from the runtime State to each of the class
- scodec to implement the codecs
done! Saving state. Easy!
Except loading. For that, would be nice to be able to patch an existing instance (the state) with the patch structure.
Unfortunately my strange use of large mutable classes full of vars
does not work here.
How it relates to existing features
Patch with bean setters would be nice.
Additional context
For my particular problem an alternative would be to load the data into new instances and re-assign some var
in the state to that new instance. Break up the State
structures a bit. shrug