A Yin/Yang class is essentially a concrete class, but did not use the
term "concrete" or RAII for three reasons:

1. Concrete has de facto pejorative connotations.  A concrete class,
unfortunately, contrasts with an abstract class.  Abstract implies
abstraction.  Abstraction is generally considered a virtue in
engineering.  Therefore, anything that contrast with abstract is,
perhaps, not as virtuous.   This is not my reasoning, but that of some
heaphaphiliacs I know.

2.  Yin/Yang symbolizes duality and symmetry.  For every action, there
is an opposite reaction.  Stack frame dropping and stack frame lifting
follow this principle.  So does order of construction and destruction
of objects as within a scope (FIFO).  Yin/Yang says that memory is
allocated in constructor, deleted in destructor. It is very rare to use
new() to instantiate a Yin/Yang class.  Instead, automatic
instantiation is sufficient, and the C++ compiler takes care of
destruction at just the right moment, even with exceptions.

3.  I wanted to point out that it is not just RAII.  The term RAII was
not used because RAII has a stronger binding to what its name implies:
it is generally bad to have an object that "exists, but does not really
exist until it has been initialized with a reference to its resource",
like MFC did with some of its classes.

IMO, and apparently that of others, the Yin/Yang style of primitive is
optimal for massive scale of systems.  They provide significant mental
relief with regard to memory management (and allows for selective
ignorance).  There is never that feeling that there might be a missing
delete somewhere, because you know where all the new()'s and delete()
are located: in the constructors and destructors of the Yin/Yang
classes. If a system is built with a high preponderance of Yin/Yang
classes versus pointer references to classes, then those pointer
referenced classes will be so few in number that they will stand out,
and can easily be spotted when trouble with memory management starts.
Classes that are constructed from nested Yin/Yang classes often
automatically become Yin/Yang classes themselves.  Such bigger classes
are often copyable and assignable using the default operations of that
of the compiler.

The biggest question, of course, is not whether such classes can be
useful and preferable to non Yin/Yang classes.  We already know they
are.  Stroustrup himself said so.

The biggest question is:

"Is it possible, for an arbitrary system, in general, to structure the
state of that system so that the Yin/Yang model is adhered to from the
microscopic level to the macroscopic level almost entirely?"

Some of us have found empirically that the answer to this question is
"Yes."  And the result is simply wonderful.

-Le Chaud Lapin-