Re: extending c++ classes and enumerations

Lourens Veen wrote:


I believe that the reference here is to the apparently widely-held
(though erroneous) belief, evident in many of the posts to this thread,
that support for extending class interfaces would undermine class
encapsulation in C++. Such fears are misplaced; in fact, the effect
would be entirely the opposite. Class extensions, properly specified,
would support class encapsulation to a greater extent than C++
currently allows.


By requiring the extension to depend only on the public interface of
the class and not on any detail of its private implementation (see
below)


But extending classes in C++ need not break their encapsulation. To
understand why, it is necessary to distinguish between two different
traits that can be used to describe any C++ function. The first is
whether the function is a member of a class interface, and the second
is whether the function's implementation has access to that class's
non-public members. Now the two traits are often conflated (and
treating the two as synonymous leads to a misunderstanding of class
extensions as a feature).

The two traits however are independent, and C++ recognizes the
difference even today. After all, a "friend" of a class is one that
possesses the latter trait (access to non-public class members) but
lacks the former one (membership in the class's interface). Note
further though that the distinction is lopsided: specifically, the
mirror image of the "friend" concept is absent from the C++ language.
There is no "relative" keyword expressing the concept that is the
mirror of a "friend". A "relative" (if the concept were to exist) would
be a member of a class interface but one which has not been granted
access to the class's non-public members. In other words: while a
friend is a non-member which the class treats as if it were a member, a
relative would be a class member treated as if it were not. And this
behavior exactly matches how we behave toward our own friends and
relatives during our rare programming breaks :-).

The ability to declare class relatives - as well as class friends -
would benefit C++ programs in a variety of ways. A few that come to
mind include:

Improved Support for Encapsulation
Class relatives would allow a program to decrease the number of
routines with privileged access to a class's private members - even as
they are likely to increase the number of class interface members
overall. Today, a great many classes (such as std::string) include a
significant number of members that do not require privileged access to
the class's non-public members, but which enjoy such privileges
nonetheless. There is no language support to deny privileged class
access to a class member. Class relatives would furnish that ability: a
function could be a member of a class interface without also enjoying
access to its non-public members. And the more restricted the access to
a class's private data, the better that class has been encapsulated.

More Focussed Class Interfaces
Let's return to our earlier example: std::string. Now nearly every one
of std::string's member functions could be implemented outside of
std::string itself. But implementing those methods as free functions
would not be an improvement. Because any class interface that combines
free and member functions is one that offers two different syntaxes
with little to account for the difference. Imagine s.find("abc") and
rfind(s, "abc") as members of std::string's interface. At the very
least, the fact that we could contemplate the possibility should be
enough to tell us that there has to be a better approach. There must be
something missing in the current C++ language that would avoid such a
predicament - and in fact, we already know what that something is.
Incidentally, it is the absent support for class relatives that leads
to the oft-repeated recommendation to prefer free functions to member
functions when designing a class interface - and to do so despite the
obvious cost to the class's usability.

On the other hand, there is little reason for a class designer to add,
say, an uppercase() method to std::string interface if mine is the only
program that would use it. So one factor in deciding whether to add a
routine to an interface is not just the usefullness of the routine for
a particular application, but also popular that kind of application
happens to be in general. So most class interfaces today represent a
series of tradeoffs, and the interface when complete is unlikely to be
the optimal interface for anyone - just the least worst interface for
everyone. The ability to declare class relatives would eliminate the
need for such compromises. Anyone could customize in ways to match
their needs - no matter how esoteric - and the interface when complete
would be both uncompromisingly lean - and precisely tailored for the
needs of the particular program.

Fewer Needless Subclasses
If class interfaces could be extended by the client, then the class
interface designer would have more reason to show restraint when
selecting its members. In particular, the designer would be less
inclined (than is the case today) to feel compelled to throw everything
but the kitchen sink into an interface, because the opportunities for
the client to extend the interface on their own are so limited and
unappealing.

We already considered free function as interface extensions. Another
proposed method of adding to an interface - through subclassing - is
even less adequate as a solution. For one, a std::string subclass
provides only a limited solution: legally the added methods can only be
used with derived class objects and not with std::strings objects in
general. Creating subclasses is also likely to become unworkable as a
solution if other modules adopt the same practice and subclass
std::string to add their own custom methods. But the primary objection
is simply on the principles of object-oriented programming itself: a
derived class refines the concept expressed in the base class.
Therefore a derived class that exists only to implement a method that
the base could implement just as well by itself (but happens not to) is
a misuse of inheritance.

So far from destroying C++ as an objected-oriented programming
language, the ability to extend class interfaces by declaring class
"relatives" would in fact only strengthen C++'s position as a modern,
objected-oriented programming language.

Greg

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]