Commit graph

5 commits

Author SHA1 Message Date
e0f866092d rectify-design(#301): disentangle CmdClosure hierarchy
Completely removed the nested hierarchy, where
the top-level implementation forwarded to yet another
sub-implementation of the same interface. Rather, this
sub-implementation (OpClosure) is now a mere implementation
detail class without VTable, and without half-baked
re-implementation of the CmdClosure interface. And the
state-switch from unbound to bound arguments is now
implemented as a plain-flat boolean flag, instead of
hiding it in the VTable.

To make this possible, without having to rewrite lots of
tests, I've created a clone of StorageHolder as a
"proof-of-concept" dummy implementation, for the sole
purpose of writing test fixtures. This one behaves
similar to the real-world thing, but cares only
for closing the command operation and omits all
the gory details of memento capturing and undo.
2016-02-07 01:41:40 +01:00
a7cd8996aa immutable-arguments(#989): proof-of concept
seems to work as assumed; we'll just have to construct
a new holder tuple in place when binding arguments.
Doesn't look too bad for me
2016-02-06 19:42:41 +01:00
91e74b0456 clean-up(#301): separate inclusions by purpose
and remove some superfluous ones
2016-02-06 19:41:21 +01:00
2fbb7ba7c9 simplification(#301): use ctor chaining to remove clutter 2016-02-06 16:42:42 +01:00
be2179ea81 command-closure-design(#301): better naming of implementation classes
Seems this was part of the confusion when looking at
the inheritance graph: Names where almost reversed
to the meaning. the ArgumentHolder was *not* the
argument holder, but the top level closure. And
the class "Closure" was not "the" Closure, but
just the argument holder. ;-)
2016-02-06 16:29:06 +01:00
Renamed from src/proc/control/command-argument-holder.hpp (Browse further)