From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,e94a7e4f6f888766
X-Google-Attributes: gid103376,public
From: "Robert I. Eachus" <eachus@mitre.org>
Subject: Re: Self-referential types
Date: 1999/10/13
Message-ID: <3804E7E0.6A0265FB@mitre.org>#1/1
X-Deja-AN: 536382600
Content-Transfer-Encoding: 7bit
References: <7ttb4a$8mq$1@nnrp1.deja.com> <s04ql7cqh1s45@corp.supernews.com>
 <3802f2db_2@news1.prserv.net> <3803B5E3.F96A6DD4@mitre.org>
 <3803c8bc_2@news1.prserv.net>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: usenet@news.mitre.org
X-Trace: top.mitre.org 939845295 971 129.83.41.77 (13 Oct 1999 20:08:15 GMT)
Organization: The MITRE Corporation
Mime-Version: 1.0
NNTP-Posting-Date: 13 Oct 1999 20:08:15 GMT
Newsgroups: comp.lang.ada
Date: 1999-10-13T20:08:15+00:00
List-Id: <comp.lang.ada>

Matthew Heaney wrote:
> 
> In article <3803B5E3.F96A6DD4@mitre.org> , Iwrote:

> >    I have to butt in here.  It may be how you do MI in Ada, and it is
> > one way, but I find it ugly.  If you treat a private access type as the
> > object, then you have to do a bit more work inside the package, but the
> > exterior looks much cleaner, and the users don't have to use 'Access at
> > all.  (Often you don't need it inside the package either.)
> 
> I think we're in agreement.

   I'm not sure we are, since I was addressing a slightly different
point.
You pass access parameters in cases where I pass a private access type
to
eliminate any visible (to the user of the abstraction) use of 'Access. 
If you need to make subclassing visible, you end up making the use of
access parameters necessary, but I believe that public subclassing is a
bad thing, and that most visible subclassing should be done using
generic packages to do mix-ins.  I wasn't really criticizing your
approach, just pointing out that
Ada supports two different idioms in this area.

> Under no circumstances should you have deep inheritance hierarchies.
> Make hierarchies broad and shallow; say, an abstract parent type and a
> non-abstract sibling derivations.  (This is the approach I use over and
> over again in my articles in the Design Patterns archive.)

  Amen!  Even when I have lots of generic mixins in the private part,
the Ada idiom seems to be that there are three types of classes:
abstract root classes,
intermediate (again abstract) subclasses when doing mixins, and the
(non-abstract) visible classes that actually have objects associated
with them.  In Ada is is almost always a bug to have a non-abstract
parent of a class.
 
> I realize this is not the OO approach of other languages, but the
> benefits are that you have far less coupling.
 
  Amen again.  Have you ever read "Nesting in Ada is for the Birds" by
Lori Clarke, and others?  It was written before Ada 83 was finalized,
and discussed the same beneficial effect on coupling when you removed
nesting of procedures.

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...