CVS difference for ais/ai-00251.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00251.txt

--- ais/ai-00251.txt	2000/12/08 00:03:42	1.3
+++ ais/ai-00251.txt	2000/12/22 00:23:09	1.4
@@ -444,3 +444,58 @@
 that here.)
+From: Tucker Taft
+Sent: Wednesday, December 20, 2000 5:51 PM
+Randy Brukardt wrote:
+> While editing Tucker's proposal, I was struck by the following:
+> ... [One possible goal would be for us to change
+> > Ada.Finalization.[Limited_]Controlled into abstract interface
+> > types.  This might require us to define an alternative to "is abstract'
+> > such as "procedure ... is null" whereby an abstract interface
+> > could establish a "null" default for an operation, since that is
+> > what Controlled provides fopr all of its operations.]
+> This "goal" seems to me to be a good way to kill off this proposal. The
+> effect of this would be to require a significant change in the way that
+> finalization is implemented. For instance, if the implementation literally
+> uses a list of Ada.Finalization.Controlled'Class to implement this, the
+> pointer size would change (assuming the use of the implementation model
+> given in the AI). Similarly, the implementation would need to handle any
+> additional data needed for finalization by some compiler magic, rather than
+> by inheritance as is currently done (assuming that abstract interface types
+> may not have components).
+I realized this was a possibility, but I wasn't sure what
+current implementation strategies actually are.  Comments
+from vendors about specific implementation problems
+with this possible change would certainly be of interest.
+In any case, I certainly hope that the
+decision whether to use abstract interfaces for
+Ada.Finalization.Controlled can be viewed as a completely separate
+issue.  I would suspect that there are other similar situations,
+even if Finalization turns out not to work for other reasons, where
+one would want to move from abstract tagged type to abstract
+interface or vice-versa during maintenance or enhancement.
+That is one of the main advantages of the
+proposed syntax, and is why I changed the suggested syntax
+from what I presented in Baltimore.
+> I note that the proposal never seems to state that abstract interface types
+> must not define any components. Certainly, the implementation model and the
+> entire discussion seem to assume that is the case. (An "normal" abstract
+> type can have components defined, they'll be part of any extension; but I
+> don't think we want that here.)
+I improperly presumed the reader knew what was meant by an
+abstract "interface" type.  It definitely doesn't have any
+data components.  That is one of the things that significantly simplifies
+multiple inheritance of interfaces.
+I also notice that an example is missing.  I will try to provide
+one over the next couple of days.

Questions? Ask the ACAA Technical Agent