comp.lang.ada
 help / color / mirror / Atom feed
* Re: derived types
@ 1989-04-23 15:33 Alex Blakemore
  0 siblings, 0 replies; only message in thread
From: Alex Blakemore @ 1989-04-23 15:33 UTC (permalink / raw)



	Re: 3.4.(15) and 7.4(4)
	>>  This disallows things like
	>>     type this is new integer;
	>>     type that is new this;
	
	>   The rationale behind this is due to the fact that a derived type receives
	> it's parents subprograms. I.E. ALRM 3.4(13):
	
	> The compiler will not know that all of these have been defined until
	> it has finished compiling the spec. This insures that everything that must
	> be derived for a new type is known.
	
	OK, the above restrictions make it easier for compilers to make a single pass
	over package specs.  That alone may justify their inclusion in the reference manual.
	Is that the only reason for these restrictions ?
	
	Cascading the derivations across several packages is probably the best
	solution but it does introduce other problems, esp if the base type is private.
	See Bardin & Thompson's papers in Ada Letters, VIII, 1-2 for examples of
	these problems and partial solutions if you're interested.
	
	                                Alex Blakemore
	                                Software Productivity Consortium

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~1989-04-23 15:33 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1989-04-23 15:33 derived types Alex Blakemore

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