From: bv@bigblue.no (B. Vermo)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: 29 Jun 1995 17:34:42 -0400
Organization: Norbionics
Sender: bv@login.bigblue.no

In article <dewar.803990850@gnat>, dewar@cs.nyu.edu (Robert Dewar) wrote:
*>If you are using OS/2, then the performance is definitely limited by the
*>rather horrible disk caching in OS/2, in particular the ludicrous limit
*>of 2 megs on the disk cache for HPFS.

If you run OS/2 and need more than 2MB disk cache for HPFS to run any
non-server program, it is something significantly wrong with the design
of your program. This implies that the program is reading and writing
the same disk records all the time instead of loading everything you need
into memory and keeping it there until you have finished.
If you are running a server-type application, you will do so on a server
and then you will use HPFS386 which does not have this cache limitation.

Smalltalk/V seems to benefit from reducing the cache size to make as
much RAM as possible available to the system. While it is not exactly
a fast system in itself, it does at least seem to be designed to work
with the operating system instead of against it.


From: bill_law@taligent.com (William A. Law)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: 28 Jun 1995 18:33:16 GMT
Organization: Taligent, Inc.

In article <Jan.Bytesmiths-2806951021280001@138.120.62.112>,
Jan.Bytesmiths@acm.org wrote:


>                                                     I'm merely saying its
> need is much greater in languages who's notion of "type" is limited to
> compile-time inheritance.

But C++ doesn't have such a limitation.  For example, what "types" do the
STL algorithms operate on?  Only objects of classes derived from a single
base "Collection" class?  Hint: there is no base Collection class in the
proposed C++ standard library.

I don't mean to argue against your main point (C++ needs MI worse than
Smalltalk does).  But toning down the rhetoric would perhaps make for a
more enlightening discussion.

Bill Law

From: rheney@csugrad.cs.vt.edu (Violet)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.c++,alt.psychotic.roommates,alt.psychology.jung
Subject: Re: Has C++ had its day?
Date: 28 Jun 1995 17:23:34 -0400
Organization: Virginia Tech Computer Science Dept, Blacksburg, VA

John Sellers says:

: In Article<3smnlg$h6@newsbf02.news.aol.com>, <emergentcy@aol.com>
: write:
: > ...
: > I think that a lot of computer types (less so now than 10 years
: > ago fortunately) are more centralization-head-discipline (chd)
: > types than decentralization-heart-freedom (dhf) types.  chd's
: > must climb to the center to effect change; dhf's are content to
: > play at the edges.
: >
: > A dhf is optimistic because it feels that it can change things
: > for the better starting right now wherever it finds itself.  A
: > chd is pessimistic because it must become or acquire or
: > convince the center - a major task not lightly undertaken.
: > ...

: I think you have got something there.  Would you consider
: elaborating on you theories and submitting them for inclusion in
: next year's edition of the "Diagnostic and Statistical Manual on
: Mental Disorder" of the American Psychiatric Association?  Also I
: have a friend of a friend of a friend who swears he can get you
: your own comedy show on prime time right after "Family Matters".


  Kick him.

  -Violet.
--
 ** 'Don't hope for miracles, rely on them.' -Hitchiker's guide to the Galaxy.
-------------------------------------------------------------------------------
            http://csugrad.cs.vt.edu/~rheney  Violet's Illusions. . .
-------------------------------------------------------------------------------

From: herbs@interlog.com (Herb Sutter)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: Wed, 28 Jun 95 22:03:37 GMT
Organization: Daystar Software Systems Design Inc.

In article <NEWTNews.804269222.4596.sellers@sellers.sellers.com>,
   John Sellers <sellers@sellers.com> wrote:
>
>There are some good OO experts who feel that multiple inheritance
>is a good thing under the right circumstances.  Bertrand Meyer
>comes to mind.  He points out the necessity of being very
>diciplined in its use.
>
>However, multiple inheritance can easily become a real rat's
>nest.  It is an open invitation to making things over complex.

All true.  Meyers (in "Effective C++") gives a pretty good treatment of this
question -- specifically as it relates to C++, yes, but many of the points
apply in general.  MI is one of those things where when you really need it,
you need it badly and nothing else will do... and when you don't, you
shouldn't be tempted because there are (complexity and other) costs
associated with using it.

>One company I worked for recently has an interesting perspective
>that emanates directly from their president.  "Simplify,
>simplify, simplify, and get the architecture right."  He has been
>able to pull a couple of big rabbits out of the hat with that
>philosophy.  I think the same philosophy is an excellent one for
>Smalltalk.  A corollary of this would be, "Never use multiple
>inheritance when single inheritance will do".  In my experience,
>I haven't found a single case on the job that single inheritance
>couldn't handle well.

I like both the slogan and your corollary; but in your last sentence don't
forget that MI is essential for mixin design -- a quite important and
powerful approach that I've personally frequently found helpful.  Examples
available upon request.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019

From: rshapiro@bbn.com (R Shapiro)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: Wed, 28 Jun 1995 18:05:04 -0400
Organization: Bolt Beranek & Newman

In article <bill_law-2806951137080001@bill-law.taligent.com>,
bill_law@taligent.com (William A. Law) wrote:

>> languages who's notion of "type" is limited to
>> compile-time inheritance.
>
>But C++ doesn't have such a limitation.  For example, what "types" do the
>STL algorithms operate on?

The "types" referenced by templates are syntactic place-holders for real
types, and the resolution is done completely at compile time.
Semantically, there's no distinction at all between using a template on
the one hand and manually writing out all the particular cases you
actually use on the other. Templates certainly don't change the static
(compile-time) nature of types in C++.

--
rs/rshapiro@bbn.com

From: John Sellers <sellers@sellers.com>
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: Thu, 29 Jun 95 00:33:20 PDT
Organization: BEST Internet (415) 964-2378


In Article<1995Jun28.140600.6412@merlin.hgc.edu>, <jcm@hgc.edu>
write:
> ...
> >However, multiple inheritance can easily become a real rat's
> >nest.  It is an open invitation to making things over complex.
>
> Well, I agree it can easily be misused, but so can nearly every

> feature in any language. ...

Slow down there.  MI is more dangerous than you give it credit
for.  MI is to OOP as goto is to structured programming.  You
don't ever what to use MI without some careful OOP think anymore
than you would ever use goto without careful structured
programming think.  Put even a little more stronger:  Your MI
tree had better be well thought out or the chances are 99% you
will end up in a mess.  With single inheritance you can
occasionally get away with being a little informal about your
approach, with MI you try that and sooner or later you are going
to pay a price.

> ...
> >Sticking with single inheritance makes it easier to structure
> >class so that each class has one main purpose in life.
>
> Perhaps. If true, wouldn't disallowing inheritance make it even
easier?

Sure you can disallow inheritance, but don't call it OOP if you
do.

> ... A number of recent
> Smalltalk posters have indicated that they don't use it to
model
> is-a-kind-of (i.e. subtyping) relationships.
> ...
> So I'm wondering just
> what you _do_ use it [inheritance] for.

I do, but I like to think of it as specialization, because I like
the connotations better.  Its not much problem to branch off in
another direction by adding instance variables for an instance
from some other part of the hierarchy in order to get some of the
effects of MI.  Also now holders, adaptors, and wrappers are
being used a lot more than they used to.  That can be a nice way
to move off in another direction and still maintain a uniform
protocol.

The flavor of doing things this way is you don't lose that sense
of a single unifying force in the current hierarchy which seem to
be a major characteristic of many of the better inheritance
hierarchies as viewed from various abstract classes within the
hierarchy.  In Visual Works, VisualComponent is an excellent
example.  ALL VisualComponents have certain nice display
characteristics, and ALL Views, which happen to be in the
VisualComponent subHierarchy, have certain other characteristics.
 If you want to get the flavor of a very nice parsing of
incrementally adding characteristics using inheritance, look
closely at the VisualComponent hierarchy in VW.
>
> >... "Never use multiple
> >inheritance when single inheritance will do".  In my
experience,
>
> Well, how about, "Never use inheritance where composition will
do."
>

Again, don't call it OOP if you do.

> ...
> What relationship, say between class A and class B, is it that
single
> inheritance handles well? And is there never a case where A
might
> have this relationship to another class, C, as well?
>
> ...

When you talk about relationships, I don't think that has much to
do with inheritance.  This sounds more like "Part of" or "Object
Connection".  You could have an instance variable called B_or_C,
or perhaps better yet, BHolder_or_CHolder, where the holders
share a common protocol and the holders act as adaptors for B and
C.

I hedged a little here, what I suggested is not a good naming
convention in most cases.  The instance variable name actually
usually would be a name of the relationship that you have with B
or C which has a significance specific to the local context.  For
example, the instance variable name might be "mailMan" and A
might be Person and B might be Robot.


From: John Sellers <sellers@sellers.com>
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: Thu, 29 Jun 95 01:57:53 PDT
Organization: BEST Internet (415) 964-2378


In Article<3ssjch$61o@steel.interlog.com>, <herbs@interlog.com> write:
> > ...  In my experience,
> >I haven't found a single case on the job that single inheritance
> >couldn't handle well.
>
> I like both the slogan and your corollary; but in your last sentence don't
> forget that MI is essential for mixin design -- a quite important and
> powerful approach that I've personally frequently found helpful.  Examples
> available upon request.
> ...

I have no argument there.  I meant my comment as an empirical
statement rather than a judgement of MI.  Of course, I may
have failed to mention that all my OOP has been in various
Smalltalks and none of them had MI.

The fact remains, I've been consulting several years and have not
had a single case where I felt that single inheritance wasn't
up to the job.  Admittedly the richness of the Smalltalk
environment may have had something to do with this.



From: John Sellers <sellers@sellers.com>
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.c++,alt.psychotic.roommates,alt.psychology.jung
Subject: Re: Has C++ had its day?
Date: Thu, 29 Jun 95 02:10:50 PDT
Organization: BEST Internet (415) 964-2378


In Article<3ssh8m$r99@csugrad.cs.vt.edu>, <rheney@csugrad.cs.vt.edu> write:
> >
> John Sellers says:
> ...
>
> : I think you have got something there.  Would you consider
> : elaborating on you theories and submitting them for inclusion in
> : next year's edition of the "Diagnostic and Statistical Manual on
> : Mental Disorder" of the American Psychiatric Association?  Also I
> : have a friend of a friend of a friend who swears he can get you
> : your own comedy show on prime time right after "Family Matters".
>
>
>   Kick him.
>
>   -Violet.
> ...

Sorry, its just that I could not resist the tempation of cross-
posting to comp.lang.smalltalk, alt.psychology.jung,
and alt.psychotic.roommates.   ;-)


From: jim.fleming@bytes.com (Jim Fleming)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: 1 Jul 1995 07:17:52 GMT

In article <NEWTNews.804552764.8937.sellers@sellers.sellers.com>,
sellers@sellers.com says...
>
>
>In Article<rshapiro-2906951349590001@esb.bbn.com>, <rshapiro@bbn.com>
write:
>> ...
>> It's a good idea to be circumspect about judging the merits of a
>> programming concept that's outside the boundaries of the languages you
>> happen to know and use. Otherwise you end up looking you're saying "I
>> don't understand how to use it, so it must be a bad idea," whether that's
>> really true or not.
>> ...
>
>Actually I've understood MI for years.  I have done MI in OOP, but I didn't
>count it because it wasn't in a full blown commercial project.  The first
>time was when I got Step Stone to do a port of Objective-C to the now
>obsolete HP9000/500 for me back in the days when I build CAD systems for
>Siemens in a Unix and C, and Step Stone was still PPI.  I don't know how
>it is now, but back then the Object-C compiler was a precompiler built
>into a Unix script.
>
>In any case, although there is no MI in Smalltalk,
>MI is just an extension of inheritance, and anyone with a long time
>experience in Smalltalk is going to understand why you would need to be
>careful with MI in a language similar to Smalltalk.
>
>Now to make a little more of a case:
>I grabbed one of my VW 2.0 Smalltalk images with only a small amount of
>development in it, Advanced Tools, C Connect, Object Explorer, and no
>database.  I then grabbed the instance side of the class hierarchy with:
>
>    (Object withAllSubclasses  select: [ :each |
>        each isKindOf: Object class])
>
>By doing a little massaging on the resulting collection, I got the
>following numbers:
>
>    # of classes w/ subclasses          349
>    # of classes w/ no subclasses       907
>    Total number of classes            1256
>    # of instance & class selectors   27816
>
>I would argue that Smalltalk has grown to push the edge in terms of
>acceptable complexity.  The best we can do is to simplify and increase
>the quality of the classes, even perhaps reduce the number of classes
>if possible (as least one could dream of this).  In comparison, a
>fresh Digitalk image in the early days was about 120 classes.  It is hard
>enough to understand this larger environment even without MI.
>
>Starting with MY VW image and assuming we have MI and subclass from any
>two classes which do not inherit from each other, I calculated that
>there would be almost 60,000 different superclass pair combinations
>possible.  In these 60000 pairs, each one would use two different disjoint
>sets of almost 28000 methods to form the protocols of your new class.
>
>Its pretty clear that the number of possible side effects is mind
>boggling, just considering two methods that happen to have the same
>name. Nobody is going to have a clear idea of what will work and what
>won't for most of the possible pairings...and this analysis is for a
>class hierarchy which started with no MI.  I don't even want to think
>of what additional complexities you would be dealing with considering
>all possible kinds of side effects and a system this size and type that
>is build using MI from the start.
>
>
@@@@@@

Yes, I agree, when an OO environment starts to mature beyond the String
class and a "hello world" program, the need to start categorizing and
the need for organization and consistency becomes essential.

C+@ was forced to support MI because in the era when C+@ was developed
(1984-1992) there was a big emphasis placed on comparing feature lists
with C++. At that time it did not seem to matter to people to compare
"results" (i.e. reusable class libraries).

MI is rarely used in the essential C+@ class library which has several
hundred classes. It looked good on the feature list but in practice
has not been a great benefit.

--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
From: rmartin@rcmcon.com (Robert Martin)
Subject: Re: Has C++ had its day?
Organization: R. C. M. Consulting Inc. 708-918-1004
Date: Thu, 29 Jun 1995 15:35:21 GMT

John Sellers <sellers@sellers.com> writes:

>A corollary of this would be, "Never use multiple
>inheritance when single inheritance will do".  In my experience,
>I haven't found a single case on the job that single inheritance
>couldn't handle well.

In dyanmically typed language like Smalltalk, this is to be expected.
Smalltalk does not require inheritance for subtyping.  But static
language like Eiffel and C++ do.  So for them, multiple inheritance is
critically important.  And barely a single project goes by that does
not benefit from it.



--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@oma.com     |   OOA/D, C++, Advanced OO
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Mgt. Overview of OOT
Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.

Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
From: rmartin@rcmcon.com (Robert Martin)
Subject: Re: Has C++ had its day?
Organization: R. C. M. Consulting Inc. 708-918-1004
Date: Thu, 29 Jun 1995 15:42:24 GMT

neil@geog.leeds.ac.uk (Neil Wilson) writes:

>Jan.Bytesmiths@acm.org wrote:
>: type compatible with it. In C++, it must. This is why Smalltalkers see
>: little need for multiple inheritance, and why C++ers can't take Smalltalk
>: seriously because it doesn't have multiple inheritance! So let's stop

>C++ doesn't have multiple inheritance. It has a hack.

The C++ implementation of multiple inheritance works quite well.
There are some compilers that have gotten in wrong in the past,
but....

I use MI all the time in C++, and have no trouble.  I disagree that it
is a "hack".  Rather I consider it to be a valuable and well deployed
tool of the language.

>: Don't get me wrong, C++ has its place (somewhere). But static typing is
>: 30-year-old technology -- attacking Smalltalk because it purposely lacks
>: it is a bit like attacking cars because there's nowhere to hang your buggy
>: whip.

>C++ belongs in a museum.

This statement seems to be non-sequitur.  The implication is that C++
is ancient and nobody uses it anymore.  But a simple look at the
industry, or even just this newsgroup will provide enough data to
dispell that notion.


--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@oma.com     |   OOA/D, C++, Advanced OO
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Mgt. Overview of OOT
Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.

Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
From: rmartin@rcmcon.com (Robert Martin)
Subject: Re: Has C++ had its day?
Organization: R. C. M. Consulting Inc. 708-918-1004
Date: Thu, 29 Jun 1995 15:58:35 GMT

Jan.Bytesmiths@acm.org writes:

>Multiple inheritance is simply yet another mechanism for adding behavior
>to an object. There was a famous paper in OOPSLA 86: "Delegation is
>Inheritance," that showed the two are equivalent.

I can see the equivalence in a dynamically typed language, but I think
That the equivalence breaks down in a statically typed language.  The
reason is that the delegator is not a subtype of the delegatee.   Now
one could fudge this by creating abstract base classes that both
inherit from, but then you have inheritance again.

>Smalltalkers lean
>heavily on delegation wherever a C++er would think of MI.

For exactly the reason above.

>In particular,
>general delegation (implementing #doesNotUnderstand:) simulates MI well
>enough to pass a black-box test, albeit less efficiently.

But not in statically typed languages.

>Having worked with both, I find delegation more controlled and easier to
>debug. Delegation is a partnership, where one object agrees to share its
>responsibilities with some other object in a manner it controls. MI is
>schizophrenia, where the poor object has no idea what its personality is
>going be from one compile to the next!

This is silly.  MI, in statically typed language, is simply the union
of two interfaces.  Assigning psychopathies to software is an
inappropriate anthropomorphism.  Objects aren't people, they cannot be
psycopathic.  They are just bits of software doing a job.  And if
their job is to mediate between two or more interfaces, well that is
nothing new or strange.


--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@oma.com     |   OOA/D, C++, Advanced OO
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Mgt. Overview of OOT
Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.

Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
From: rmartin@rcmcon.com (Robert Martin)
Subject: Re: Has C++ had its day?
Organization: R. C. M. Consulting Inc. 708-918-1004
Date: Thu, 29 Jun 1995 16:02:34 GMT

rshapiro@bbn.com (R Shapiro) writes:

>In article <bill_law-2806951137080001@bill-law.taligent.com>,
>bill_law@taligent.com (William A. Law) wrote:

>>> languages who's notion of "type" is limited to
>>> compile-time inheritance.
>>
>>But C++ doesn't have such a limitation.  For example, what "types" do the
>>STL algorithms operate on?

>The "types" referenced by templates are syntactic place-holders for real
>types, and the resolution is done completely at compile time.
>Semantically, there's no distinction at all between using a template on
>the one hand and manually writing out all the particular cases you
>actually use on the other. Templates certainly don't change the static
>(compile-time) nature of types in C++.

Yes, but this is like saying that there is no semantic difference
between a polymorphic method invocation and a typecase statement.  It
is true, but it misses the point.   C++ provides certain language
features (e.g.  templates) which provide a form of polymophism that is
not based upon types, but is based upon interface only.

To say this another way, The "type" conformance of a template argument
is not based upon inheritance.  It is only based upon whether the
actual argument posesses all the interfaces that the template
implementation uses.


--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@oma.com     |   OOA/D, C++, Advanced OO
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Mgt. Overview of OOT
Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.

From: rshapiro@bbn.com (R Shapiro)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: Thu, 29 Jun 1995 13:49:59 -0400
Organization: Bolt Beranek & Newman

In article <NEWTNews.804416848.25886.sellers@sellers.sellers.com>, John
Sellers <sellers@sellers.com> wrote:

> I may
>have failed to mention that all my OOP has been in various
>Smalltalks and none of them had MI.
>
>The fact remains, I've been consulting several years and have not
>had a single case where I felt that single inheritance wasn't
>up to the job.


Of course you do realize that there may be a logical connection between
these two statements, right? It's very difficult to see the utility of
functionality that you can never actually use (because the only language
you know doesn't support it).

Over in comp.lang.c++, some people are saying the same sorts of things
about closures, and it's not unusual to read posts from c++-only
programmers making similar claims about meta-object support ("haven't seen
a single case where I really need it"). Not coincidentally, C++ doesn't
support either of these.

It's a good idea to be circumspect about judging the merits of a
programming concept that's outside the boundaries of the languages you
happen to know and use. Otherwise you end up looking you're saying "I
don't understand how to use it, so it must be a bad idea," whether that's
really true or not.

--
rs/rshapiro@bbn.com

From: pdlogan@ornews.intel.com (Patrick Logan)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: 29 Jun 1995 19:48:00 GMT
Organization: Intel Corporation

Herb Sutter (herbs@interlog.com) wrote:

: MI is one of those things where when you really need it,
: you need it badly and nothing else will do.

: don't...
: forget that MI is essential for mixin design -- a quite important and
: powerful approach that I've personally frequently found helpful.

MI is a mechanism for solving more than one problem. There are other
solutions for solving the same problems. I would like to see a proof
that "nothing else will do" in any given circumstance.

As for "mixins", it is possible to create mixins in languages like
Smalltalk that do not (usually) have MI. An object plays the role of
a "mixin" by subscribing to one or more specific protocols. MI is one
mechanism some languages provide for subscribing to protocols. Some
languages provide other mechanisms.

--
Patrick_D_Logan@ccm.jf.intel.com
Intel/Personal Conferencing

"Form follows function." -Le Corbusier



From: jim.fleming@bytes.com (Jim Fleming)
Newsgroups: comp.object,comp.lang.c++,comp.lang.smalltalk,comp.lang.misc
Subject: Re: Has C++ had its day?
Date: 29 Jun 1995 20:10:32 GMT
Organization: Unir Corporation

In article <1995Jun29.201630.9031@rcmcon.com>, rmartin@rcmcon.com says...
>
@@@@@@@

Thanks for your questions. I will try to provide some answers. I hope
that others familiar with C+@ help also...:)

@@@@@@@

>jim.fleming@bytes.com (Jim Fleming) writes:
>
>>class String {
>>/**
>>*      String objects are used to store a collection of characters
>>*      which can be accessed as an array of bytes. The size of the
>>*      array can be increased or descreased as the need arises. The
>>*      current count of the number of active bytes is maintained in
>>*      each instance.
>>*
>>*      An implied null (or zero value) byte is assumed, in some cases,
>>*      to follow the last active byte. This does not preclude the
>>*      ability of storing a zero value byte in the string.
>>*
>>*/
>
>>class inherit class AbstractArray;
>>inherit AbstractArray;
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>These two statements confuse me.  I assume that they mean that
>String inherits from AbstractArray.  Fine.  But why two statements?
>
@@@@@

The first statement is used to specify that the "class methods" are
inherited by the String class.

The second statement indicates that the "istance methods" are inherited.

C+@ has the ability to selectively inherit methods and to "map"
method names. Neither of these are show above. The above statements
cause wholesale inheritance of AbstractArray.

I assume that you will want to see the sample code for AbstractArray
at some point.

@@@@@

>Sorry for not knowing C+@ syntax, but I'm here to learn.
>
@@@@@

I am always willing to help. I am willing to change. I am willing to
look at various views. I am also willing to program in many languages.
Diversity and alternatives are part of the joy of the human experience.

@@@@@

>If String inherits from AbstractArray, are you sure that you want that?
>Are there interfaces of AbstractArray that are inappropriate for String?
>
@@@@@

String started out on its own. It turned out that common behavior was
best grouped in AbstractArray. For the discussion here, we might want to
first work on the interface for String and then see what is common. I
guess this gets into the area of debating whether a String is a fancy
term for an array of bytes or whether it has a higher level of abstraction.

If and when we get into the discussion on Unicode, it may become clear
that Strings could be more than byte arrays. It is not clear to me which
way the majority of people prefer to go on this. There are some serious
issues about performance and the need to drag Unicode into every discussion
on Strings.

@@@@@

>>// Instance Variables
>
>>long size; // The current size of the string including any 0 value bytes.
>>char buffer[]; // The indexable instance variable that holds the bytes.
>
>>// C+@egory: Creation
>
>>class method (String _) new (Integer size)
>>/**
>>*      Create a new String object with 'size' bytes of storage.
>>*              Example: a = String.new(80);
>>*/
>>{
>>       ...
>>}
>
>>class method (String _) allocate (Integer size)
>>/**
>>*      Create a new String object with 'size' bytes of storage.
>>*              Example: a = String.allocate(80);
>>*
>>*/
>>{
>>       ...
>>}
>
>What is the difference between allocate and new?  They seem to
>do the same thing?
>
@@@@@@@@@

Yes, this is true. Yet more legacy because of indecision during the
analysis and design process.

I would prefer to pick one....should we take a vote...???

BTW, other class methods could be recommended that create String objects.
There is no restriction on the names. For example, String.ofBlanks(245)
might be useful. There has to be some balance between need, design,
expressiveness, performance, and probably most importantly consistency.

@@@@@@@@@

>>class method (String _) {} (values[])
>>/**
>>*      Create a new String from the list of values.
>>*              Example: a = { 'H', 'e', 'l', 'l', 'o' };
>>*/
>>{
>>       ...
>>}
>
>Is it true in C+@ that arguments do not need types?  What if the array
>did not contain chars?
>
@@@@@@@@

Yes, that is true...

I will probably state this over and over, but there is a difference
between describing the "interface" that an argument uses or honors and
it's type. The values above can be anything as long as they honor the
expected interface. We should probably write:

  class method (String _) {} (Integer values[])
  /**
  * Create a new String from the list of values
  * where each value must support the Intger interface.
  */
  {
    ...
  }

@@@@@@@@

>>// C+@egory: Accessing
>
>>method (String _) [] (Integer index)
>>/**
>>*      Return the value located at the position indicated by 'index'.
>>*      The first value is indexed by 0.
>>*              Example: a = string[5];
>>*/
>>{
>>       ...
>>}
>
>I'd like to see the implementation of this function.  I am wondering
>how the char at buffer[index] gets converted into a String.
>
@@@@@

..very good question...
..more on this later...

@@@@@

>>method (String _) []= (Integer index, Integer value)
>>/**
>>*      Set the value located at the position indicated by 'index'
>>*      to the 'value' specified.
>>*      The first value is indexed by 0.
>>*              Example: string[5] = 'A';
>>*/
>>{
>>       ...
>>}
>
>I like this operator []=.  Good idea.  But why is 'value' an integer
>instead of a String or a char?
>
@@@@@

Fortunately (or Unfortunately) the Integer is largely used as a comment
because string["hello"] = "world" is OK.

I prefer to spec this one as:

  method (_) []= (index,value)

This seems simpler and cleaner to me and "our" C+@ compiler will treat
it the same as above.

If we look at the semantics of C+@, we find that methods are selected
based on the selector and the NUMBER of arguments not the types. This
is a case where the semantics should be understood by the designers
and commentary class information may actually mislead rather than help.

I am sure that this will be a point of discussion.

@@@@@

>>// C+@egory: Operations
>
>>method (String _) << (String addition)
>>/**
>>*      ConC+@enate the additional string to a copy of the receiver
>>*      and return the result.
>>*
>>*/
>>{
>>       ...
>>}
>

@@@@@

The + operator could also be used for concatenation.
We could also come up with a variety of operators which help
to distinguish between appending to an existing string (which
can grow) and a forced copy with eventual concatenation.

This is one of those areas where I am not sure the word
desciptions or the operators are more expressive.

@@@@@

>>// C+@egory: Version Management
>
>>class method (_) versionId { _ = "0.0"; }
>
>>} // String
>
>>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>
>>The Interface for the above is:
>
>>class String {
>
>>// C+@egory: Creation
>>class method (String _) new (Integer size)
>>class method (String _) allocate (Integer size)
>>class method (String _) {} (values[])
>
>>// C+@egory: Accessing
>>method (String _) [] (Integer index)
>>method (String _) []= (Integer index, Integer value)
>
>>// C+@egory: Operations
>>method (String _) << (String addition)
>
>>// C+@egory: Version Management
>>class method (_) versionId { _ = "0.0"; }
>
>>} // String
>
>
>--
>Robert Martin       | Design Consulting   | Training courses offered:

@@@@@@@@@@@@@@

Thanks for your questions...

I hope that we can define a standard interface. Obviously, there are
many, many more methods that are needed...fortunately, we do not have
to trouble ourselves with the combinatorial nightmare of argument
typing...

--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|


From: jim.fleming@bytes.com (Jim Fleming)
Newsgroups: comp.object,comp.lang.c++,comp.lang.smalltalk,comp.lang.misc
Subject: Re: Has C++ had its day?
Date: 29 Jun 1995 20:13:36 GMT
Organization: Unir Corporation

In article <id.KY2L1.Q24@nmti.com>, peter@nmti.com says...
>
>Except of course Jim never seems to get to the "tossing source back and
>forth" stage...
>--
>Peter da Silva    (NIC: PJD2)                             `-_-'

@@@@@@@@@@@@@@@

I posted a start for a String class for discussion. For some reason
the original posting seems to have disappeared...:)...it must have
been a "machine error"...

--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|


Newsgroups: comp.object,comp.lang.c++,comp.lang.smalltalk,comp.lang.misc
From: rmartin@rcmcon.com (Robert Martin)
Subject: Re: Has C++ had its day?
Organization: R. C. M. Consulting Inc. 708-918-1004
Date: Thu, 29 Jun 1995 20:16:30 GMT

jim.fleming@bytes.com (Jim Fleming) writes:

>class String {
>/**
>*  String objects are used to store a collection of characters
>*  which can be accessed as an array of bytes. The size of the
>*  array can be increased or descreased as the need arises. The
>*  current count of the number of active bytes is maintained in
>*  each instance.
>*
>*  An implied null (or zero value) byte is assumed, in some cases,
>*  to follow the last active byte. This does not preclude the
>*  ability of storing a zero value byte in the string.
>*
>*/

>class inherit class AbstractArray;
>inherit AbstractArray;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

These two statements confuse me.  I assume that they mean that
String inherits from AbstractArray.  Fine.  But why two statements?

Sorry for not knowing C+@ syntax, but I'm here to learn.

If String inherits from AbstractArray, are you sure that you want that?
Are there interfaces of AbstractArray that are inappropriate for String?

>// Instance Variables

>long size; // The current size of the string including any 0 value bytes.
>char buffer[]; // The indexable instance variable that holds the bytes.

>// C+@egory: Creation

>class method (String _) new (Integer size)
>/**
>*  Create a new String object with 'size' bytes of storage.
>*    Example: a = String.new(80);
>*/
>{
> ...
>}

>class method (String _) allocate (Integer size)
>/**
>*  Create a new String object with 'size' bytes of storage.
>*    Example: a = String.allocate(80);
>*
>*/
>{
> ...
>}

What is the difference between allocate and new?  They seem to
do the same thing?


>class method (String _) {} (values[])
>/**
>*  Create a new String from the list of values.
>*    Example: a = { 'H', 'e', 'l', 'l', 'o' };
>*/
>{
> ...
>}

Is it true in C+@ that arguments do not need types?  What if the array
did not contain chars?

>// C+@egory: Accessing

>method (String _) [] (Integer index)
>/**
>*  Return the value located at the position indicated by 'index'.
>*  The first value is indexed by 0.
>*    Example: a = string[5];
>*/
>{
> ...
>}

I'd like to see the implementation of this function.  I am wondering
how the char at buffer[index] gets converted into a String.

>method (String _) []= (Integer index, Integer value)
>/**
>*  Set the value located at the position indicated by 'index'
>*  to the 'value' specified.
>*  The first value is indexed by 0.
>*    Example: string[5] = 'A';
>*/
>{
> ...
>}

I like this operator []=.  Good idea.  But why is 'value' an integer
instead of a String or a char?

>// C+@egory: Operations

>method (String _) << (String addition)
>/**
>*  ConC+@enate the additional string to a copy of the receiver
>*  and return the result.
>*
>*/
>{
> ...
>}

>// C+@egory: Version Management

>class method (_) versionId { _ = "0.0"; }

>} // String

>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

>The Interface for the above is:

>class String {

>// C+@egory: Creation
>class method (String _) new (Integer size)
>class method (String _) allocate (Integer size)
>class method (String _) {} (values[])

>// C+@egory: Accessing
>method (String _) [] (Integer index)
>method (String _) []= (Integer index, Integer value)

>// C+@egory: Operations
>method (String _) << (String addition)

>// C+@egory: Version Management
>class method (_) versionId { _ = "0.0"; }

>} // String


--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@oma.com     |   OOA/D, C++, Advanced OO
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Mgt. Overview of OOT
Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.

From: bv@bigblue.no (B. Vermo)
Newsgroups: comp.object,comp.lang.c++,comp.lang.smalltalk
Subject: Re: Has C++ had its day?
Date: 29 Jun 1995 17:34:40 -0400
Organization: Norbionics
Sender: bv@login.bigblue.no

In article <jyobxj@bmtech.demon.co.uk>,
Scott Wheeler <scottw@bmtech.demon.co.uk> wrote:

*>
*>Pardon me, but no, I've got nothing against him challenging
*>assumptions, and sometimes he has something interesting to say at this
*>phase of the cycle. I was speaking literally when I said that he
*>compares the C++ community with Nazi Germany.

It seems that people fitting the popular labels "genius", "paranoid" and
"psychopath" are somewhat over-represented in our community. It also
looks like it is more common than in society at large that some people
implicitly will cathegorize others in such a way, whether it is deserved or not.
Usually, it looks like most of the people in question will have something
worthwile to contribute much of the time, but the mixture certainly
will create som unneccessarily long threads.

One cathegory I have problems with, however, is the "one tool for all
purposes" community. I did have tendencies in that direction myself
at one time when the only languages I knew were Algol-60, FORTRAN
and COBOL. Since then, I have come to the conclusion that it is better
to use the tool which suits the problem to be solved. Early on, it was
a major feat to be able to link a routine written in one language to
a program written in another language. Today, we see the same thing
with object oriented languages. Until we can easily make objects from
different development systems interwork, we will not reap the benefits
of object orientation. And the language-specific zealots are a major
hindrance to acheive that level of functionality.


From: dewar@cs.nyu.edu (Robert Dewar)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: 29 Jun 1995 19:08:27 -0400
Organization: Courant Institute of Mathematical Sciences

One of the reasons that Ada did not follow C++ and provide some kind
of specific built-in multiple inheritance was that, despite a lot of
effort, we failed to find any convincing examples that suggest that
this is a good idea.


Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
From: Robb.Nebbe@di.epfl.ch (Robb Nebbe)
Date: 30 Jun 1995 07:11:57 GMT
Sender: nebbe@lglsun3.epfl.ch (Robb Nebbe)
Organization: Ecole Polytechnique Federale de Lausanne

In article <1995Jun29.153521.5115@rcmcon.com>, rmartin@rcmcon.com (Robert Martin) writes:

|> In dyanmically typed language like Smalltalk, this is to be expected.
|> Smalltalk does not require inheritance for subtyping.  But static
|> language like Eiffel and C++ do.  So for them, multiple inheritance is
|> critically important.  And barely a single project goes by that does
|> not benefit from it.

Eiffel without MI would be crippled; MI is an integral part of the
language. In C++ it is already less important and is just a useful
addition to the language. There is nothing special about MI that
makes it essential to a statically typed language; the functionality
may be provided through other means.

Robb Nebbe

From: dewar@cs.nyu.edu (Robert Dewar)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: 30 Jun 1995 07:59:53 -0400
Organization: Courant Institute of Mathematical Sciences

"If you run OS/2 and need more than 2MB disk cache for HPFS to run any
non-server program, it is something significantly wrong with the design
of your program. This implies that the program is reading and writing
the same disk records all the time instead of loading everything you need
into memory and keeping it there until you have finished.
If you are running a server-type application, you will do so on a server
and then you will use HPFS386 which does not have this cache limitation."

well this is exactly the same misconception that IBM obviously labors
under. It is completely wrong for typical compile intensive compilation
environments.

When you do a series of operations, edit, compile, etc. You are running
separate programs. These programs will touch many files. Most notably
for example in the case of GNAT, the executable itself is larger than 2 megs,
so with the puny 2 meg cache, the executable always has to be loaded from
disk, and you haven't even started putting out temporary files etc.

You can't "put everything in memory" if you are passing information between
separate programs (e.g. a compiler and assembler), unless you tightly
integrate everything, which has obvious disadvantages.


The fact of the matter is that the relative performance of OS/2 compared
with NT on large scale compilations using *any* compiler that I have used
is horrible due to this 2 meg cache limitation. I have put a 12 meg VDISK
on my system, and that doubled compilation speeds, but it is a kludgy
way of doing things that would be quite unnecessary if OS/2 had a proper
cache limit. Note that this silly limit does not apply to FAT systems,
and in fact GNAT and many other programs run much faster under FAT than
under HPFS because of this on a large system.

The idea that only "server applications" whatever that may mean, need a
reasonable sized cache is just bogus. The only reason for the silly 2 meg
limitation is that OS/2 inherits some old junk 16-bit coding in this
area.

Yes, the solution is indeed to go to HPFS386, but you have to buy a lot of
other junk to do that. Why IBM has not yet made HPFS386 a standard easily-
available file system, I have no idea.

I was encouraged by Timoth Sipples (I assume you know who he is) to report
this as a bug, and I did so, he certainly agrees it is a very unfortunate
limitation. Of course most people stlil have very small systems, but as I
have noted in other messages here, configuring a Pentium machine with 32meg
or 64meg for a large scale development machine makes perfect sense, and
if you have 64meg of memjory, using only 2 meg of cache is silly (my PC
will currently accomodate up to 384 meg of memory!)

If you *do* integrate a system more tightly, one technical approach you
can use is precisely to keep the compiler resident as a kind of server,
stashing away stuff in virtual memory. This will get around the cache
problem, but means that the VM stays tied up. The Intermetrics compiler
uses this approach, they call it source paging. It is an obvious idea
which we have on and off considered for GNAT, but I am not sure that it
would buy us enough to be worth having GNAT depart that far from the normal
GCC model, thought it would not be hard to do.

Of course another real advantage of the source paging approach (I will use
the Intermetrics term since it seems a reasonable one), is that if you have
large specs used by several successive compilations, you do not have to
recompile them, which will certainly have speed advantages.

We really don't know how fast the GNAT front end will be when it is in
something like the final form (no debugging information, tree reorganized
to allow more efficient indexing, everyhing inlined). We will get a big
speed up in the front end when we do this (a factor of several), and then
we will have to evaluate whether introducing some kind of persistance makes
sense. The system is obviously cleaner with the zero-persistance approach
we use now, so we don't want to move away from this unless the gain is
substantial.


From: Theodore Dennison <dennison@escmail.orl.mmc.com>
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: 30 Jun 1995 12:01:51 GMT
Organization: Martin Marietta Marine Systems

rmartin@rcmcon.com (Robert Martin) wrote:
>John Sellers <sellers@sellers.com> writes:
>
>>A corollary of this would be, "Never use multiple
>>inheritance when single inheritance will do".  In my experience,
>In dyanmically typed language like Smalltalk, this is to be expected.
>Smalltalk does not require inheritance for subtyping.  But static
>language like Eiffel and C++ do.  So for them, multiple inheritance is
>critically important.  And barely a single project goes by that does
>not benefit from it.

Ada is a staticly-typed language, and it does not rely on inheritance
for subtyping. I believe the same goes for Modula-3 and Oberon.

The problem here isn't static or dynamic typing, its C++.

T.E.D.


Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
From: jcm@hgc.edu (James McKim)
Subject: Re: Has C++ had its day?
Sender: usenet@merlin.hgc.edu (Action News Central)
Organization: The Hartford Graduate Center
Date: Fri, 30 Jun 1995 14:22:20 GMT

In article <NEWTNews.804415994.23097.sellers@sellers.sellers.com> John Sellers <sellers@sellers.com> writes:
>
>In Article<1995Jun28.140600.6412@merlin.hgc.edu>, <jcm@hgc.edu>
>write:
>> ...
>> >However, multiple inheritance can easily become a real rat's
>> >nest.  It is an open invitation to making things over complex.
>>
>> Well, I agree it can easily be misused, but so can nearly every
>
>> feature in any language. ...
>
>Slow down there.  MI is more dangerous than you give it credit

Is it? How much have you used MI? I use inheritance for subtyping
almost exclusively and fine that MI comes up quite naturally in
virtually every application. As you might guess from my .sig I use
Eiffel, which has very clear and straightforward semantics for
dealing with the issues that MI presents. I rarely have difficulty.

>for.  MI is to OOP as goto is to structured programming.  You

It can be misused in a way similar to the way goto was misused. The
solution to the goto problem was not to implement an artificial
rule on the number of goto's in the program. Instead, people imposed
a discipline on the way they used goto (branching, loops, procedure calls).
Later, languages were designed that enforced this discipline. I am
trying to understand what discipline is enforced by limiting a language
to single inheritance.

>don't ever what to use MI without some careful OOP think anymore
>than you would ever use goto without careful structured

I agree.

>programming think.  Put even a little more stronger:  Your MI
>tree had better be well thought out or the chances are 99% you
>will end up in a mess.  With single inheritance you can
>occasionally get away with being a little informal about your
>approach, with MI you try that and sooner or later you are going
>to pay a price.

Perhaps. I suspect our experiences with MI are vastly different.

>
>> ...
>> >Sticking with single inheritance makes it easier to structure
>> >class so that each class has one main purpose in life.
>>
>> Perhaps. If true, wouldn't disallowing inheritance make it even
>easier?
>
>Sure you can disallow inheritance, but don't call it OOP if you
>do.

Well, some people won't call it OOP if you disallow MI, but so what?
I note that you didn't answer my question.

>
>> ... A number of recent
>> Smalltalk posters have indicated that they don't use it to
>model
>> is-a-kind-of (i.e. subtyping) relationships.
>> ...
>> So I'm wondering just
>> what you _do_ use it [inheritance] for.
>
>I do, but I like to think of it as specialization, because I like
>the connotations better.  Its not much problem to branch off in

Fine, I agree that specialization has slightly different connotations
than subtyping (although I'm not sure we'd agree on what those differences
are :-)). This strikes me as a reasonable discipline to enforce when
deciding whether to use inheritance or not. So what are these terrible
problems that arise if you enforce the same discipline in the use
of multiple inheritance?

>another direction by adding instance variables for an instance
>from some other part of the hierarchy in order to get some of the
>effects of MI.  Also now holders, adaptors, and wrappers are
>being used a lot more than they used to.  That can be a nice way
>to move off in another direction and still maintain a uniform
>protocol.

Yes, of course you can simulate MI. That is not the issue.

>
>The flavor of doing things this way is you don't lose that sense
>of a single unifying force in the current hierarchy which seem to
>be a major characteristic of many of the better inheritance
>hierarchies as viewed from various abstract classes within the
>hierarchy.  In Visual Works, VisualComponent is an excellent
>example.  ALL VisualComponents have certain nice display
>characteristics, and ALL Views, which happen to be in the
>VisualComponent subHierarchy, have certain other characteristics.
> If you want to get the flavor of a very nice parsing of
>incrementally adding characteristics using inheritance, look
>closely at the VisualComponent hierarchy in VW.

If I understand correctly, Views inherit from  VisualComponent and
add extra features. That is, the descendants don't hide any
ancestors' features ot subvert their meanings. If so, this sounds
like subtyping to me.


[..]

>
>> ...
>> What relationship, say between class A and class B, is it that
>single
>> inheritance handles well? And is there never a case where A
>might
>> have this relationship to another class, C, as well?
>>
>> ...
>
>When you talk about relationships, I don't think that has much to
>do with inheritance.  This sounds more like "Part of" or "Object
>Connection".  You could have an instance variable called B_or_C,
>or perhaps better yet, BHolder_or_CHolder, where the holders
>share a common protocol and the holders act as adaptors for B and
>C.

Well, unless I've misinterpreted the above, it seems that you use
inheritance for subtyping (an is-a-kind-of relationship. OTOH if
I'm wrong and you truly can't verbalize
when it's appropriate to use inheritance, then I can certainly understand
how you would have difficulty benefiting from multiple inheritance.


[..]

Interesting discussion,
-- Jim


--

*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458     Co-editor of Eiffel Outlook
Internet:  jcm@hgc.edu        Subscribe early and often!

From: rshapiro@bbn.com (R Shapiro)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: Fri, 30 Jun 1995 10:46:24 -0400
Organization: Bolt Beranek & Newman

In article <1995Jun29.155835.5444@rcmcon.com>, rmartin@rcmcon.com (Robert
Martin) wrote:

>Jan.Bytesmiths@acm.org writes:
>
>>Multiple inheritance is simply yet another mechanism for adding behavior
>>to an object. There was a famous paper in OOPSLA 86: "Delegation is
>>Inheritance," that showed the two are equivalent.


Of course, formal equivalence doesn't mean one isn't preferable to the
other from a design perspective.


>I can see the equivalence in a dynamically typed language, but I think
>That the equivalence breaks down in a statically typed language.

In other words, statically typed languages *need* mi, whereas dynamic ones
have straightforward ways to get around it. But that doesn't mean mi isn't
useful in dynamic languages. I use it routinely in CLOS, for the simple
reason that it's sometimes the cleanest way to do something. I'd do the
same in Smalltalk if it supported mi. The fact that, without too much
difficulty, I can hack up a formally equivalent alternative approach that
doesn't use mi doesn't really interest me very much.


>>Smalltalkers lean
>>heavily on delegation wherever a C++er would think of MI.
>
>For exactly the reason above.

Not at all. They "lean" on it because they have no choice, although if
they haven't used mi elsewhere, they probably don't even realize they're
leaning. C++ programmers "lean" unknowingly in the same way when they need
meta-object support, or closures, or other things the language doesn't
support.

--
rs/rshapiro@bbn.com

From: glascock@esd.dl.nec.com (Trent Glascock)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: 30 Jun 1995 14:52:26 GMT
Organization: Engineering and Support Division, NEC, Inc.

In article <Jan.Bytesmiths-2606951420580001@138.120.62.112>, Jan.Bytesmiths@acm.org says...
>Interpretation has nothing to do with it. The two leading Smalltalk
>implementations are NOT interpreted, and numerous minor ones are not
>interpreted either.

In VisualWorks source code is converted to "byte codes" at "compile
time".  "Byte codes" are converted to "machine code" at run time.
Sounds like an interpreter tokenizing then interpreting to me.

>Smalltalk has strong dynamic typing based on object signatures. (Never
>heard of that? Look it up -- it's in the literature.) It does not do
>static typing.

Strong dynamic typing?  In your Smalltalk code you can send any
message to any object.  The system will only warn you if no object
currently in your image implements that message.  At run time the
object is checked to see if it can receive the message.  No type
checking of the parameters is performed.  I don't call that "strong
dynamic typing" I call that dynamic linking.

>C++ has strong static typing based on class inheritance. It does not do
>dynamic typing.

C++ static typing is not based on class inheritance at all.  C++
polymorphism is based on class inheritance.  Static type checking
is based on the programmer telling the compiler the type of all
objects and the compiler checking the validity of all operations
on that object.  And it does do dynamic typing with the addition
of RTTI and dynamic casts.  Of course your definition of dynamic
typing will vary.

>Don't get me wrong, C++ has its place (somewhere). But static typing is
>30-year-old technology -- attacking Smalltalk because it purposely lacks
>it is a bit like attacking cars because there's nowhere to hang your buggy
>whip.

Don't get _me_ wrong, Smalltalk has its place (somewhere).  But static
typing helps make a program type safe.  Of all of the shortcomings in
C++, its approach to type safety is not high on the list.  Implying
static typing is archaic because your language doesn't support it is
sophomoric.

--
Trent Glascock
glascock@esd.dl.nec.com

Speaking only for myself


From: rshapiro@bbn.com (R Shapiro)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: Fri, 30 Jun 1995 10:54:05 -0400
Organization: Bolt Beranek & Newman

In article <1995Jun29.160234.5549@rcmcon.com>, rmartin@rcmcon.com (Robert
Martin) wrote:

>rshapiro@bbn.com (R Shapiro) writes:
>
>>In article <bill_law-2806951137080001@bill-law.taligent.com>,
>>bill_law@taligent.com (William A. Law) wrote:
>
>>>> languages who's notion of "type" is limited to
>>>> compile-time inheritance.
>>>
>>>But C++ doesn't have such a limitation.  For example, what "types" do the
>>>STL algorithms operate on?
>
>> Templates certainly don't change the static
>>(compile-time) nature of types in C++.
>
>Yes, but this is like saying that there is no semantic difference
>between a polymorphic method invocation and a typecase statement.



Sigh. Read the context, Bob. The claim was made the templates show that
C++ doesn't have a "compile-time inheritance" limitation. I explained why
this was false, by showing that templates don't alter the semantics of the
language in that way.

You don't *really* disagree, do you?

I didn't say that templates are useless, or that they didn't improve the
modularity of the language. They do -- in fact, they're *necessary* if the
language is to satisfy one of your own principles. What I said was that
they don't alter the semantics of the language at all. Even Stroustrup
says as much.

--
rs/rshapiro@bbn.com

From: bill_law@taligent.com (William A. Law)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: 30 Jun 1995 18:28:09 GMT
Organization: Taligent, Inc.

In article <rshapiro-3006951054050001@ipa.bbn.com>, rshapiro@bbn.com (R
Shapiro) wrote:

> Sigh. Read the context, Bob. The claim was made the templates show that
> C++ doesn't have a "compile-time inheritance" limitation.

Big sigh.  Having made the "claim," please let me say that it wasn't the
claim you describe.  I was claiming that C++'s "notion of type" was *not*
limited to compile-time inheritance, which was the claim (paraphrased, at
least), that I was refuting.

Clearly, templates demonstrate some "notion" (an admittedly vague term) of
"type" that transcends inheritance.

In more concrete terms, consider the Smalltalk method:

    foo: anObject
      ^foo bar

What "type" of objects can I apply this method to?  Those that respond to
the message "bar" and which return from that message an object compliant
with the "type" expected by the sender of "foo."

OK, now consider the C++ function:

   int foo( T &anObject ) { return anObject.bar(); }

What "type" of objects can I apply this funtion to?  Those that are of
type T or some class derived from T.  In other words, type is limited to
inheritance in C++ (or so it seems).

Now consider
    template <class T>
    int foo( T &anObject ) { return anObject.bar(); }

What "type" of objects can I apply this function to now?  Those that
respond to the function "bar" and which returns from that function a type
compliant with the "type" expected by the caller of "foo" (int, in this
case).

I would hope the distinction is obvious to even the most bigoted of
Smalltalk devotees.

Bill

From: dweller@Starbase.NeoSoft.COM (David Weller)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: 30 Jun 1995 14:24:01 -0500
Organization: NeoSoft Internet Services   +1 713 968 5800

In article <1995Jun30.142220.4193@merlin.hgc.edu>,
James McKim <jcm@hgc.edu> wrote:
>Eiffel, which has very clear and straightforward semantics for
>dealing with the issues that MI presents. I rarely have difficulty.
>

And you shouldn't.  Eiffel has MI rather well-integrated into the
language.  I think the whole issue opens itself up to debate because
of a few key issues here:

  1.  Not everybody agrees on what form of MI is "right".
      The C++ version of MI and the Eiffel version of MI are
      different.  There's also the "implementation" vs.
      "interface" argument.
  2.  There is a long list of successful projects using SI, or
      SI+templates.  There is not a long list of industrial
      projects where MI was commonly used (to my knowledge...I
      suppose that's open to argument also :-) (And even if you
      were to find an example in language X, you will find
      detractors that say, "You would do it thusly in language
      Y, just as easily.  And language Y doesn't have MI")
  3.  There's somewhat universal agreement that MI serves a
      useful purpose in design and analysis, but some claim
      that MI in implementation reduces reusability.
  4.  There's a bit of irony (at least in the C++ domain) that
      the C++ Booch Components are used as an example of
      "industrial" MI (see Bjarne's "D&E" book, pg 271), yet
      the components no longer have MI (they were "designed
      out" to improve flexibility).

For now, I don't think we're going to solve the argument.  There's
too much diversity, and too little evidence that MI is one of those
godsends that will get people to use OO methods by the droves.  This
is part of the reason that "modern" languages like Ada95 left MI out
(but didn't rule it out totally for future language revisions).



From: rshapiro@bbn.com (R Shapiro)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: Fri, 30 Jun 1995 16:40:48 -0400
Organization: Bolt Beranek & Newman

In article <bill_law-3006951131290001@bill-law.taligent.com>,
bill_law@taligent.com (William A. Law) wrote:
>Big sigh.  Having made the "claim," please let me say that it wasn't the
>claim you describe.  I was claiming that C++'s "notion of type" was *not*
>limited to compile-time inheritance, which was the claim (paraphrased, at
>least), that I was refuting.
>
>Clearly, templates demonstrate some "notion" (an admittedly vague term) of
>"type" that transcends inheritance.

No, they don't. Templates are like macros, a kind of syntactic shorthand.
The parameters of a template are *not* C++ types, and it's shows a
fundamental confusion to refer to them as if they were (with or without
scare quotes). They're compile-time placeholders for types. Types, in C++,
are limited in just the way you keep insisting they aren't.


>Now consider
>    template <class T>
>    int foo( T &anObject ) { return anObject.bar(); }
>
>What "type" of objects can I apply this function to now?

You can't apply this "function" to anything, because it isn't a function.
It's a specification of a way for the compiler to generate a family of
functions for you automatically. *Those* functions are as statically typed
as anything else in C++. A template is closer to a compiler directive than
it is to a function, a kind of smart #define statement.

Templates do NOT change the nature of types in C++ in any way whatsoever.

--
rs/rshapiro@bbn.com

Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
From: jcm@hgc.edu (James McKim)
Subject: Re: Has C++ had its day?
Sender: usenet@merlin.hgc.edu (Action News Central)
Organization: The Hartford Graduate Center
Date: Fri, 30 Jun 1995 21:20:50 GMT

In article <3t0p3f$hjl@theopolis.orl.mmc.com> Theodore Dennison <dennison@escmail.orl.mmc.com> writes:

[..]

>
>Ada is a staticly-typed language, and it does not rely on inheritance
>for subtyping. I believe the same goes for Modula-3 and Oberon.

Hmm... Then I guess I should ask you the same question I asked an
earlier Smalltalk poster. If you don't you inheritance to support
subtyping, what _do_ you use it for?


[...]

>T.E.D.
>


Just askin',
-- Jim
--

*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458     Co-editor of Eiffel Outlook
Internet:  jcm@hgc.edu        Subscribe early and often!

From: John Sellers <sellers@sellers.com>
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: Fri, 30 Jun 95 15:48:40 PDT
Organization: BEST Internet (415) 964-2378


In Article<rshapiro-2906951349590001@esb.bbn.com>, <rshapiro@bbn.com> write:
> ...
> It's a good idea to be circumspect about judging the merits of a
> programming concept that's outside the boundaries of the languages you
> happen to know and use. Otherwise you end up looking you're saying "I
> don't understand how to use it, so it must be a bad idea," whether that's
> really true or not.
> ...

Actually I've understood MI for years.  I have done MI in OOP, but I didn't
count it because it wasn't in a full blown commercial project.  The first
time was when I got Step Stone to do a port of Objective-C to the now
obsolete HP9000/500 for me back in the days when I build CAD systems for
Siemens in a Unix and C, and Step Stone was still PPI.  I don't know how
it is now, but back then the Object-C compiler was a precompiler built
into a Unix script.

In any case, although there is no MI in Smalltalk,
MI is just an extension of inheritance, and anyone with a long time
experience in Smalltalk is going to understand why you would need to be
careful with MI in a language similar to Smalltalk.

Now to make a little more of a case:
I grabbed one of my VW 2.0 Smalltalk images with only a small amount of
development in it, Advanced Tools, C Connect, Object Explorer, and no
database.  I then grabbed the instance side of the class hierarchy with:

    (Object withAllSubclasses  select: [ :each |
        each isKindOf: Object class])

By doing a little massaging on the resulting collection, I got the
following numbers:

    # of classes w/ subclasses          349
    # of classes w/ no subclasses       907
    Total number of classes            1256
    # of instance & class selectors   27816

I would argue that Smalltalk has grown to push the edge in terms of
acceptable complexity.  The best we can do is to simplify and increase
the quality of the classes, even perhaps reduce the number of classes
if possible (as least one could dream of this).  In comparison, a
fresh Digitalk image in the early days was about 120 classes.  It is hard
enough to understand this larger environment even without MI.

Starting with MY VW image and assuming we have MI and subclass from any
two classes which do not inherit from each other, I calculated that
there would be almost 60,000 different superclass pair combinations
possible.  In these 60000 pairs, each one would use two different disjoint
sets of almost 28000 methods to form the protocols of your new class.

Its pretty clear that the number of possible side effects is mind
boggling, just considering two methods that happen to have the same
name. Nobody is going to have a clear idea of what will work and what
won't for most of the possible pairings...and this analysis is for a
class hierarchy which started with no MI.  I don't even want to think
of what additional complexities you would be dealing with considering
all possible kinds of side effects and a system this size and type that
is build using MI from the start.



From: John Sellers <sellers@sellers.com>
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: Fri, 30 Jun 95 15:59:21 PDT
Organization: BEST Internet (415) 964-2378


In Article<3t133a$72j@bsdsun.esd.dl.nec.com>, <glascock@esd.dl.nec.com>
write:
> ...
> In VisualWorks source code is converted to "byte codes" at "compile
> time".  "Byte codes" are converted to "machine code" at run time.
> Sounds like an interpreter tokenizing then interpreting to me.
> ...

Not exactly.  It is converted to machine code the first time it is
executed, however the machine code is retained and next time it
executes the machine code is executed directly.  That doesn't sound
like interpreting to me.


From: herbs@interlog.com (Herb Sutter)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Subject: Re: Has C++ had its day?
Date: Fri, 30 Jun 95 23:58:31 GMT
Organization: Daystar Software Systems Design Inc.

In article <3sv01g$rsu@ornews.intel.com>,
   pdlogan@ornews.intel.com (Patrick Logan) wrote:
>As for "mixins", it is possible to create mixins in languages like
>Smalltalk that do not (usually) have MI. An object plays the role of
>a "mixin" by subscribing to one or more specific protocols. MI is one
>mechanism some languages provide for subscribing to protocols. Some
>languages provide other mechanisms.

All right, as long as the mixin supplies interface only.  But what about
mixins that also supply behaviour, such as a Publisher/Subscriber (or, as
GoF calls it, Observer) model implemented in base mixin classes?

I don't know Smalltalk well, so I'll ask: Does its protocol subscription
allow the equivalent of behaviour inheritance from multiple bases?

Regards,

Herb


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019

Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Has C++ had its day?
Organization: The World Public Access UNIX, Brookline, MA
Date: Sat, 1 Jul 1995 00:52:58 GMT

In article <1995Jun30.212050.26112@merlin.hgc.edu>,
James McKim <jcm@hgc.edu> wrote:
>In article <3t0p3f$hjl@theopolis.orl.mmc.com> Theodore Dennison <dennison@escmail.orl.mmc.com> writes:
>>Ada is a staticly-typed language, and it does not rely on inheritance
>>for subtyping. I believe the same goes for Modula-3 and Oberon.
>
>Hmm... Then I guess I should ask you the same question I asked an
>earlier Smalltalk poster. If you don't you inheritance to support
>subtyping, what _do_ you use it for?

Ada 95 is pretty new, but I think subtyping will be a major use of Ada
95's new inheritance feature.  (Unfortunately, Ada confuses the issue
by having something called a "subtype", which is completely different
from what OOP folks normally call a subtype.  But anyway, subtyping
in the OOP sense is supported.)

- Bob

Newsgroups: comp.object,comp.lang.c++,comp.lang.smalltalk,comp.lang.misc
From: kapson@netcom.com (John Kapson)
Subject: Re: Has C++ had its day?
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Sat, 1 Jul 1995 02:18:09 GMT
Sender: kapson@netcom14.netcom.com

In article <3sv1bp$26o@News1.mcs.net> jim.fleming@bytes.com (Jim Fleming) writes:
[snip]
>>>class inherit class AbstractArray;
>>>inherit AbstractArray;
>>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>These two statements confuse me.  I assume that they mean that
>>String inherits from AbstractArray.  Fine.  But why two statements?
>>
>@@@@@
>
>The first statement is used to specify that the "class methods" are
>inherited by the String class.
>
>The second statement indicates that the "istance methods" are inherited.
>
>C+@ has the ability to selectively inherit methods and to "map"
>method names. Neither of these are show above. The above statements
>cause wholesale inheritance of AbstractArray.

Does this imply, then, that C+@ provides one the ability to inherit
class methods from one class while inheriting instance methods from
a second, unrelated class?  I'm struggling to see how this fits into
the traditional mold of using inheritance to support the "IS-A"
relation...

John

Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
From: jcm@hgc.edu (James McKim)
Subject: Re: Has C++ had its day?
Sender: usenet@merlin.hgc.edu (Action News Central)
Organization: The Hartford Graduate Center
Date: Wed, 28 Jun 1995 14:06:00 GMT

In article <NEWTNews.804269222.4596.sellers@sellers.sellers.com> John Sellers <sellers@sellers.com> writes:
>
>In Article<1995Jun27.121935.4921@merlin.hgc.edu>, <jcm@hgc.edu>
>write:
>> ...
>>
>> I'm genuinely curious about why Smalltalkers (or at least a
>number who
>> have posted here) find inheritance to be important and useful,
>but do
>> not feel the same way about multiple inheritance. ...
>
>There are some good OO experts who feel that multiple inheritance
>is a good thing under the right circumstances.  Bertrand Meyer
>comes to mind.  He points out the necessity of being very
>diciplined in its use.
>
>However, multiple inheritance can easily become a real rat's
>nest.  It is an open invitation to making things over complex.

Well, I agree it can easily be misused, but so can nearly every
feature in any language. And I agree it adds complexity to
the language, although most of this is due to the special case
of repeated inheritance. The question is whether its
benefits offset the additional complexity. There's a tradeoff
involved. Smalltalk has chosen simplicity in this case.


[...]

>
>Sticking with single inheritance makes it easier to structure
>class so that each class has one main purpose in life.

Perhaps. If true, wouldn't disallowing inheritance make it even easier?
Surely single inheritance can be misused as well. This is another tradeoff.
Smalltalk has chosen complexity in this case.

You see the more important question in my original post had to do
with how Smalltalkers typically use inheritance. A number of recent
Smalltalk posters have indicated that they don't use it to model
is-a-kind-of (i.e. subtyping) relationships. So I'm wondering just
what you _do_ use it for. Once I have some feeling for that, I can
perhaps better understand why it makes sense to include single,
but not multiple inheritance.

>
>One company I worked for recently has an interesting perspective
>that emanates directly from their president.  "Simplify,
>simplify, simplify, and get the architecture right."  He has been
>able to pull a couple of big rabbits out of the hat with that
>philosophy.  I think the same philosophy is an excellent one for
>Smalltalk.  A corollary of this would be, "Never use multiple
>inheritance when single inheritance will do".  In my experience,

Well, how about, "Never use inheritance where composition will do."

>I haven't found a single case on the job that single inheritance
>couldn't handle well.

What relationship, say between class A and class B, is it that single
inheritance handles well? And is there never a case where A might
have this relationship to another class, C, as well?

Best,
-- Jim

>


--

*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458     Co-editor of Eiffel Outlook
Internet:  jcm@hgc.edu        Subscribe early and often!

