comp.lang.ada
 help / color / mirror / Atom feed
From: Tucker Taft <stt@avercom.net>
Subject: Re: Abstract Functions
Date: Mon, 16 Jul 2001 17:43:57 -0400
Date: 2001-07-16T21:43:58+00:00	[thread overview]
Message-ID: <3B53601D.1295AF39@avercom.net> (raw)
In-Reply-To: 9ihs6j$k33$1@nh.pace.co.uk

Marin David Condic wrote:
> 
> That is one possible way to go. However, what I have is a working parent
> type that does useful things in its own right. It would be useful to have a
> way of keeping it executable, but adding one or more operations that would
> require extension. Basically, if you have a type that is a few generations
> down the inheritance tree and now want to add some abstract operations, the
> only way to do that is make the whole tree of types abstract. I'd prefer not
> to do that.

That's not true.  Abstractness is *not* inherited.  An
abstract type can have a non-abstract parent, and vice-versa.
So you could have a useful non-abstract "grandparent" type,
an abstract immediate parent, and then a non-abstract
child of this parent.  Also remember that functions that
return the type will automatically become abstract on
inheritance, and thereby require overriding.

> 
> Its the sort of thing where I've gone down a chain of inheritance and said
> "O.K. Now I need the user to provide me with some functions and I don't want
> to make this generic." I suppose I could use pointers to functions but I've
> never liked that answer.
> 
> A question I could get answered by the compiler, but maybe this is less
> typing: Can I have an abstract tagged type that has data fields? My
> recollection of examples I've seen have not had data - just null records.

As someone else pointed out, abstract types can have as
many components as you want.  They can also have non-abstract
operations.  They can pretty much have everything a non-
abstract type has (except for non-abstract functions that
return the type).

> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
> 
> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:6b_27.15423$Kf3.181711@www.newsranger.com...
> > In article <9ihnia$i8h$1@nh.pace.co.uk>, Marin David Condic says...
> > >
> >
> > I believe you can have non-abstract primitive subprograms for abstract
> types.
> > What's wrong with doing that?

-- 
-Tucker Taft   stt@avercom.net   http://www.avercom.net
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Bedford, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/~stt)



  parent reply	other threads:[~2001-07-16 21:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-11 14:24 Abstract Functions Marin David Condic
2001-07-11 15:22 ` Ted Dennison
2001-07-11 15:43   ` Marin David Condic
2001-07-11 16:35     ` Ehud Lamm
2001-07-11 17:08       ` Marin David Condic
2001-07-11 17:27     ` Ted Dennison
2001-07-16 21:43     ` Tucker Taft [this message]
2001-07-16 22:15       ` Marin David Condic
2001-07-16 21:51     ` Stephen Leake
  -- strict thread matches above, loose matches on Subject: below --
2001-07-11 14:49 Re[2]: " ANH_VO
2001-07-11 19:01 ` tmoran
2001-07-12 14:10   ` Marin David Condic
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox