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.)
next prev parent 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