On 06/07/2010 06:36 AM, Kagamin wrote:
Andrei Alexandrescu Wrote:
I think an honest discussion - as I hope is the tone in TDPL -
serves the language and its users better than giving half of the
story.
An honest advertisement is an unusual thing. I saw none. You think,
TDPL is the first one. There're many features in other languages no
speak of costs, and every forgotten cost is a lie.
Agreed. Well, we'll see. I try to discuss costs, tradeoffs, and
alternative approaches that were considered and rejected (and why) for
all major features of D.
For example, few books give a balanced view of dynamic polymorphism; in
some you'll find the nice parts, in others you'll find the not-so-nice
parts. I tried to discuss both in TDPL:
====================
\dee's reference semantics approach to handling class objects is
similar to that found in many object-oriented languages. Using
reference semantics and \idx{garbage collection} for class objects has
both positive and negative consequences, among which the following:
\begin{itemize*}
\item[+]\index{polymorphism}\emph{\textbf{Polymorphism.}} The level
of indirection brought by the consistent use of references enables
support for \idx{polymorphism}. All references have the same size,
but related objects can have different sizes even though they have
ostensibly the same type (through the use of inheritance, which
we'll discuss shortly). Because references have the same size
regardless of the size of the object they refer to, you can always
substitute references to derived objects for references to base
objects. Also, arrays of objects work properly even when the actual
objects in the array have different sizes. If you've used C++, you
sure know about the necessity of using pointers with
\idx{polymorphism}, and about the various lethal problems you
encounter when you forget to.
\item[+]\emph{\textbf{Safety.}} Many of us see \idx{garbage
collection} as just a convenience that simplifies coding by
relieving the programmer of managing memory. Perhaps surprisingly,
however, there is a very strong connection between the infinite
lifetime model (which \idx{garbage collection} makes practical) and
memory safety. Where there's infinite lifetime, there are no
dangling references, that is, references to some object that has
gone out of existence and has had its memory reused for an unrelated
object. Note that it would be just as safe to use value semantics
throughout (have \cc{auto a2 = a1;} duplicate the @A@ object that
@a1@ refers to and have @a2@ refer to the copy). That setup,
however, is hardly interesting because it disallows creation of any
referential structure (such as lists, trees, graphs, and more
generally shared resources).
\item[--]\emph{\textbf{Allocation cost.}} Generally, class objects
must reside in the \index{garbage collection}garbage-collected heap,
which generally is slower and eats more memory than memory on the
stack. The margin has diminished quite a bit lately but is still
nonzero.
\item[--]\emph{\textbf{Long-range coupling.}} The main risk with
using references is undue aliasing. Using reference semantics
throughout makes it all too easy to end up with references to the
same object residing in different---and unexpected---places.
In~Figure~\vref{fig:aliasing}, @a1@ and @a2@ may be arbitrarily far
from each other as far as the application logic is concerned, and
additionally there may be many other references hanging off the same
object. Interestingly, if the referred object is immutable, the
problem vanishes---as long as nobody modifies the object, there is
no coupling. Difficulties arise when one change effected in a
certain context affects surprisingly and dramatically the state as
seen in a different part of the application. Another way to
alleviate this problem is explicit duplication, often by calling a
special method @clone@, whenever passing objects around. The
downside of that technique is that it is based on discipline and
that it could lead to inefficiency if several parts of an
application decide to conservatively clone objects ``just to be
sure.''
\end{itemize*}
Contrast reference semantics with value semantics \`a~la @i...@. Value
semantics has advantages, notably equational reasoning: you can always
substitute equals for equals in expressions without altering the
result. (In contrast, references that use method calls to modify
underlying objects do not allow such reasoning.) Speed is also an
important advantage of value semantics, but if you want the dynamic
generosity of \idx{polymorphism}, reference semantics is a must. Some
languages tried to accommodate both, which earned them the moniker of
``impure,'' in contrast to pure object-oriented languages that foster
reference semantics uniformly across all types. \dee is impure and
up-front about it. You get to choose at design time whether you
use~OOP for a particular type, in which case you use \kidx{class};
otherwise, you go with @struct@ and forgo the particular~OOP amenities
that go hand in hand with reference semantics.
====================
Andrei
