comp.lang.ada
 help / color / mirror / Atom feed
From: "Robert I. Eachus" <rieachus@attbi.com>
Subject: Re: problem with abstract types
Date: Mon, 04 Nov 2002 15:18:10 GMT
Date: 2002-11-04T15:18:10+00:00	[thread overview]
Message-ID: <3DC68FB2.1040503@attbi.com> (raw)
In-Reply-To: wccu1j12pe0.fsf@shell01.TheWorld.com

Robert A Duff wrote:

> Right, but if the code can't figure out the Tag of Reg when it is
> created, or if the Tag changes over time, then Reg will have to be of
> an access-to-Registry'Class type.  But that does not imply that all
> the operations need to take access parameters.  They can take Registry
> parameters, and you would then pass Reg.all as the actual parameter.

Bob, this is at best overkill in this case.  I can imagine a situation 
where you might want to copy data from one type of registry to another 
that would require having two open registries with different tags.  But 
even in that case, you have as an invariant that every object of type 
registry has a single tag value, and it must be determinable when the 
registry is opened.  Open registries morphing their types underneath a 
program boggles the mind.

I guess that there is a meta-rule here.  To paraphrase Einstein, "The 
user view of a data structure should be as simple as possible, but no 
simpler."  ;-) The "extra" work the implementor of an abstraction may 
have to accept to keep the visible abstraction simple is just good 
software engineering.

Ada goes to a lot of hard work to allow simple abstractions to be 
implemented with little or no run-time overhead.  In this particular 
case, the compiler might generate better code for the case with a 
classwide variable initialized at open than for an access to classwide 
type varible.  But I don't see that "savings" as the real reason for 
implementing an abstraction correctly.  The real benefit is that the 
user of the abstraction doesn't have to sweat the details if the 
abstraction is a good match to "reality," whatever that means to the 
user of the abstraction.

For example, if you are writing avionics software, "this aircraft" is an 
implicit constant.  Some of its attributes, such as weight or current 
airspeed may change, but avionics software does not expect to find 
itself in a new aircraft during flight.  If you are working on air 
traffic control software, "this aircraft" is a variable, and in fact, 
you even have to change the type of aircraft associated with a 
particular track.  (Mostly from unknown to a particular class, but that 
is a detail.)




  reply	other threads:[~2002-11-04 15:18 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-31 12:06 problem with abstract types Ulrich Eckhardt
2002-10-31 13:15 ` John English
2002-10-31 14:43   ` Ulrich Eckhardt
2002-10-31 17:18     ` Robert I. Eachus
2002-10-31 18:20       ` Jeffrey Carter
2002-10-31 20:58         ` Robert I. Eachus
2002-11-01 10:57       ` Ulrich Eckhardt
2002-11-01 12:05         ` Simon Wright
2002-11-01 17:03           ` Robert A Duff
2002-11-04 15:18             ` Robert I. Eachus [this message]
2002-11-04 16:14               ` Robert A Duff
2002-10-31 13:32 ` David C. Hoos
2002-10-31 13:47   ` problem with posters Peter Hermann
2002-10-31 14:15     ` Preben Randhol
2002-10-31 14:35   ` problem with abstract types Ulrich Eckhardt
2002-11-01  8:31     ` Dmitry A.Kazakov
2002-11-01 11:32       ` Ulrich Eckhardt
2002-10-31 15:31 ` Simon Wright
2002-10-31 17:22 ` Stephen Leake
2002-11-01 10:25   ` Ulrich Eckhardt
2002-11-04 14:30     ` Ted Dennison
2002-11-04 15:08     ` Ulrich Eckhardt
2002-11-04 15:32       ` Stephen Leake
2002-11-04 17:12         ` Ulrich Eckhardt
2002-11-04 17:43           ` David C. Hoos
2002-11-04 19:34             ` Ulrich Eckhardt
2002-11-04 19:54             ` Stephen Leake
2002-11-04 20:08             ` Robert A Duff
2002-11-01 11:15   ` Preben Randhol
2002-11-01 17:21     ` Stephen Leake
replies disabled

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