Commit graph

8 commits

Author SHA1 Message Date
b58427e49f Command-Framework: mark anonymous commands
It turns out we *do* support the use of anonymous commands
(while it is not clear yet if we really need this feature).

Basically, client code may either create and register a new
instance from another command used as prototype, by invoking
Command::storeDef(ID). Or, alternatively it may just invoke
newInstance() on the command, which creates a new handle
and a valid new implementation (managed by the handle as
smart-ptr), but never stores this implementation into the
CommandRegistry. In that case, client code may use such a
command just fine, as long as it cares to hold onto that
handle; but it is not possible to retrieve this command
instance later by symbolic ID.

In the light of this (possible) usage pattern, it doesn't
make sense to throw when accessing a command-ID. Rather, we
now return a placeholder-Symbol ("_anonymous_")
2016-12-25 21:46:58 +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
7be1b7d35d Switch from TR1 preveiw to the new standard headers
- functional
- memory
- unordered collections
2014-04-03 22:42:48 +02:00
b9d1899486 cleanup: rectify Proc-Layer namespaces (II) 2011-12-02 17:50:44 +01:00
3f1b7651e9 GPL header whitespace 2010-12-17 23:28:49 +01:00
fdd940feba clone builder implemented; problem resolved according to test 2009-10-11 05:57:45 +02:00
bb7ff5e317 WIP draft of clone builder implementation 2009-10-11 05:57:45 +02:00
a4ad41a4e9 Idea how to solve the problem with cloning the UNDO functor 2009-10-11 05:57:45 +02:00