Elaborating on the major strengths of C++ to be over Pop-11+ObjectClass
Jonathan Cunningham makes a number of interesting points. In fact I
considered several of these points at length before designing ObjectClass
and deliberately took a different route. Here's my angle on Jonathan's
remarks.
> 1) Virtual/non-virtual base classes. This means that when you have
> multiple inheritance so that the same "grandparent" is inherited by two
> or more different routes, you can specify whether you get one copy of it
> or several.
This refers one of the primary policy decisions in ObjectClass -- you only
ever get one copy. My interpretation of inheritance is that the child
type is supposed to behave like the parent type. This is idempotent.
Inheriting twice is no different from inheriting once.
The example Jonathan goes onto provide illustrates the fundamental
requirement -- that method definitions treat slot access differently
depending on which class they are compiled in. This is perfectly
viable in C++ where methods and classes are declared together. However,
ObjectClass separates the class definition from any subsequent method
definitions, so this idea is not practical.
The advantage of the ObjectClass approach is that methods may be defined and
extended independently. It also leads to a much simpler interpretation of
inheritance and name space design. The disadvantage is that this "trick" is
not possible. I think this is a tradeoff I am still like.
> 2) Non-virtual member functions (methods) (these are not the same as
> static member functions - which are like class variables). These look
> like a restriction, because you can't mess with them in a derived class.
> They are probably as irritating as using top-level lvars in a library in
> pop11, but enable the class library programmer to write secure code
> which the person using the library can't screw up. I think they are a
> cleaner way to do it than the pop11 way.
My comment on this is that lexical slots work in exactly this fashion.
Perhaps I've missed the point here?
A key design decision was to use the Pop11 name space control mechanisms
rather than invent new, wacky ones. This was motivated by looking at
the name space control mechanisms of C++. I feel that the ability to
create "hidden" slots by simply declaring them as "lvars" is one of the
most elegant consequences of the approach I chose.
> 3) Type checking. I wish pop11 had the *option* of type declarations.
> They are a real pain a lot of the time, but are nice to have if you want
> it. I like the CL/CLOS approach: optional type declarations which can
> either be used for type-checking at run-time or to produce faster code
> depending on your compiler settings.
I made a mistake here. I followed the existing type declaration technology,
namely typespec declarations. I did this in the hope that these would
become effective programming devices. I regret this decision. Hopefully
John Gibson will address this if/when ObjectClass becomes integrated
with Pop11.
> 4) The public/private inheritance distinction. Another artificial
> example: if you wanted to implement a stack class built on an array
> class, you could use private inheritance: the array is inherited for
> implementation, but a stack is not an array. Public inheritance implies
> an ako relationship between the classes.
This is the same issue as (1). This is another feature of marginal
value -- the intent is to use inheritance as a pure implementation
technique as opposed to a descriptive technique. I concede it is
pleasant to be able to do this but it relies on being able to determine
slot behaviour according to lexical context.
> 5) This is like (2) above, different public/protected/private access to
> data members (instance variables) and member functions of a class. You
> don't need to protect your users from accessing classes in the wrong way
> - but it is a good idea for writing safe, maintainable code. Sections
> are at the wrong level of granularity (and I don't like sections
> anyway.)
I agree that sections are rather poor. (That's why we implemented
modules.) However, they do give all the capability required in
principle. The issue of granularity I believe refers to the fact
that there is no way of exporting declared identifiers by default
from a section.
So basically, this is an advantage of C++. The cost is yet another
name space control mechanism. I hope that my decision will eventually
prove correct when sections are sorted out.
The last two points (destructors and stack-allocated objects) relate
to memory management issues. I shall not comment beyond stating that
C & C++ both suffer profoundly from the lack of automatic memory
management. As a consequence, these points seem very weak.
Steve
|