Ticket #301 (new planned)
Opened 2 years ago
CmdClosure design critique
| Reported by: | ichthyo | Owned by: | ichthyo |
|---|---|---|---|
| Priority: | lesser | Milestone: | 2beta |
| Component: | lumieraProc | Keywords: | QA cleanup design performance |
| Cc: | Blocked By: | ||
| Blocking: | #144 |
Description
Now, after roughly finishing the first implementation round, I'm unhappy with some parts of the command implementation. Especially the closure related parts feel somewhat misaligned.
- difficult to understand
- need to know too much implementation details so see how it works
- possible waste of storage by using too much vtables
- danger of template bloat by having too much virtual functions in templated subclasses
To my current understanding, the assets within this part of the command handling framework are:
- having a separate setup and usage API
- the usage API is small and not specifically typed (type erased)
- all storage is in-line and of limited size; handling of this is separated from the closure logic
- Command and even Closure doesn't know anything of the memento; UNDO state is completely owned by the implementing functions
Note: See
TracTickets for help on using
tickets.
