Re: A Change In Terminology: Monomorphic Objects. Polymorphic Objects
Le Chaud Lapin wrote:
I read in a concurrent post that the fad that "everything is an object"
is on the way out. That's probably good - I have seen designs where
the classes are actually nothing more than collections of functions
wrapped in something that just happens to have the word "class affixed
to it":
class MemoryScanner
{
virtual Scan (...)
// 20 virtual functions, many of which are global functions in
disguise
// 2 member variables.
} ;
class MemoryScannerBigMem : MemoryScanner
{
virtual Scan (...)
} ;
class MemoryScannerFactory()
{
MemoryScanner * GetMemoryScanner();
} ;
MemoryScannerFactory *pMemScannerFactory = new MemoryScannerFactory();
MemoryScanner pMemScan = pMemScannerFactory->GetMem..
Uggh...I get nauseous trying to finish even this small example. But
you get the point. Everything is verb-oriented. Many virtual
functions. Much new()'ing. Much delete()'ing. The mood when reading
the code is "do this, do that." It is almost as if the programmer is
allergic to state. In any case, this style of programming leads too
much getting, and doing, and verifying, and initializing....
You have noticed that C++ (like most programming languages that compile
into machine executables) is an "imperative" programming language. A
program written in an imperative computer language is told where to
start, what to do next, what to do after that, and so at every step of
its execution. Imperative languages are popular, since the programs
they describe can readily be transformed into a corresponding sequence
of machine instructions for a microprocessor.
Occasionally, the thing that is being "got" is not well-formed (read,
the programmer has not figured out its true nature), so there is a
necessity to make it polymorphic. This in turn leads to other issues
such as lifetime management, etc.
There is a different style of programming that resists the
verb-oriented paradigm. It focuses instead on what things are instead
of what they do, on the principle that, if you know what it is, you
already know what it does. The above example rewritten would be:
class MemoryScanner
{
void Scan(...) ;
} ;
MemoryScanner scanner;
scanner.Scan(...);
Now this second form has no pointers involved, and there are no
ownership issues. You certainly do not "get" a memory scanner. You
"use" one that you make, on the stack. This is only possible, of
course,if the programmer exercises sufficient forethought to determine
the nature of that which is being objectified so that virtual functions
can be obviated. This, in turn, presumes that it is even possible that
a quasi-terminal form for the latter can be found. That is a matter of
another debate however.
You are describing a "declarative" programming language. A declarative
programming language describes something - how that description is used
is outside the domain of the language. So unlike an imperative
programming, there is no notion of a strict "execution sequence" as
there is in an imperative program. XSLT and Microsoft's XAML would be
two examples (the former is a langugage for describing an XML document
transformation, the latter is a language to describe the appearance and
behavior of a user interface).
When I discuss the difference between these styles of programming to
other C++ programmers, I find myself at a loss for good terms. In my
mind, the second Scanner is just as much an object as the the first.
In fact, I would say that an object is a thing, and since a purely
abstract class cannot even be instantiated, then it could be regarded
as less of a thing than a concrete object.
What shall we call the second type of programming? Concrete?
Monomophic? Dead?
Imperative.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]