"Catherine: actually, what do you..." <- > <@mwkmwkmwk:matrix.org> Catherine: actually, what do you think about this proposal for RFC 62 amendment: > > - `MemoryData` grows `__getitem__`, which returns either `MemoryRow` (single item) or `MemorySlice` > - `sim.memory_read` and `sim.memory_write` are removed > - `sim.get` is made to accept `MemoryData` (returns the whole thing as a tuple), `MemorySlice` (returns a tuple), `MemoryRow` (returns a single int / `from_bits`) > - `sim.set` likewise accepts `MemoryData` and `MemorySlice` (value must be an interable of matching size), and `MemoryRow` > - `sim.changed` accepts `MemoryData`, `MemorySlice`, `MemoryRow`; for `MemoryRow`, behavior is as if it was a signal; for the other two, you get a dict of `{address: new_value}` containing only the changed elements > - `sim.tick.sample` from your proposal likewise accepts those three, same semantics as `sim.get` > - `traces` likewise accepts `MemoryData`, `MemorySlice`, `MemoryRow` `MemorySlice` seems fully redundant with `MemoryRow`; I don't like adding two new classes for this; if we add both "row" and "slice" I'll probably want them to be one class (though not entirely sure) also if they're called `MemoryData.Row` and `MemoryData.RowSlice` (or something) my objection subsides, though I still want to consider using one class for this (there is the obvious downside of value dependent type polymorphism, but maybe it improves things in other ways?)