> Here you go.... this was still laying in my mbox...
>
> aids
Thanks for forwarding Steve's remarks.
Hi Steve!
> > 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.
I agree, the issues are related, so I'll answer both of your remarks
together.
> > 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.
Yes, normally. But not always. (I haven't got time to do a full reply to
this. :-) Oh well, what's time anyway? ...
The usual (a usual?) way to achieve this kind of thing in objectclass
would be to have a slot which contained an instance of the object being
used for implementation, e.g. a stack class implemented using an array
could have a slot called "itsArray". Then, by ensuring that the slot
names are different, it is not difficult to arrange for multiple
inheritance to generate multiple (implementation) arrays if needed. It
would be tricky to have the choice of duplicate or share without
slot-renaming syntax. It is easier in C++, and gets relatively easier as
the examples get more complex. That's all.
Incidentally, I don't agree that slot behaviour would need to depend on
lexical context. I guess this may depend on some details of your
implementation of objectclass, or I may be misunderstanding you. Slot
access would depend on the type of the object attempting the access,
which it surely does anyway. But I also agree that you can use the
section mechanism (or some other name-space control mechanism) for this,
if you have to do it.
> > 2) Non-virtual member functions (methods) (these are not the same as
>
> My comment on this is that lexical slots work in exactly this fashion.
That's because they are the same thing! I didn't know you had lexical
slots -- see disclaimer in original message.
> 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.
I disagree strongly here. I agree about C but not about C++. See my
original posting about memory management and C++. For the vast
majority of C++ programs, stack allocated memory is a big win. For most
of the remainder, the use of destructors and references simplifies heap
memory management so that it is not a problem (nor a source of errors).
Don't judge C++ by the C programs written in it :-).
For a tiny number of complex programs, you probably want to use
reference counts (smart pointers) or even a garbage collector. For C++
most people will buy in a garbage collected class/class library, in the
same way that they buy libraries for persistent objects (OODBs). But I
haven't needed a GC yet, the most complex thing I've done used a
combination of smart pointers (with reference counts) and dumb pointers
(where a smart pointer would have created a reference loop).
I would agree that it will be better when, one day, these memory
management classes come as standard. But I wouldn't agree that an
argument in favour of automatic heap management is an argument against
C++.
So why do I prefer Lisp[1] to C++ for prototyping? I think the bottom
line is the incremental compiler.
--jlc
[1] I'm not using poplog/pop11 because it is not available on either of
the machines I'm using: a 486PC and a Mac LC3. But I don't think I would
have used Poplog anyway: I am making *really* heavy use of data
structure browsers (the INSPECT function) and it is nice to have several
inspector windows open at once. This is the kind of thing where a GUI is
a big win - any chance of the poplog debugging facilities being updated
(maybe they have but I don't have the latest version? - the "inspect"
library dates back to 1987, although it has been maintained up to 1991,
and the venerable debug library (no help file) was written in 1982, last
updated 1988). I'm sure I must be out of touch on what is available in
Poplog for assisting program development. What *do* people use? Hard
work?
|