CVS difference for ai05s/ai05-0125-1.txt

Differences between 1.10 and version 1.11
Log of other versions for file ai05s/ai05-0125-1.txt

--- ai05s/ai05-0125-1.txt	2011/03/17 07:06:29	1.10
+++ ai05s/ai05-0125-1.txt	2011/04/01 04:07:22	1.11
@@ -823,3 +823,148 @@
 at the meeting.
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, March 16, 2011  5:05 PM
+
+I am tempted to suggest we give up on AI-125, where we are trying to allow the
+overriding of an operation that is inherited but never declared.  It will become
+incompatible if we eliminate the "preference" rule for operations that *are*
+declared, and the wording is already getting pretty baroque.
+
+Comments?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 16, 2011  7:09 PM
+
+Well, the AI is already incompatible (in that not giving an indicator is not
+allowed in some cases, while it would declare a new subprogram in Ada 95). What
+we don't want is any inconsistencies (where the routine dispatched to changes
+between Ada 95 and Ada 2012). So if there is a way to make the wording have that
+effect, I'd like to see it. (Especially as the remaining problem involved
+interfaces, which I (a) could care less about; and (b) are pretty uncommon
+anyway. It's annoying to have to give up on useful functionality because of some
+corner case with a rarely used feature.)
+
+But having said that, I admit that I couldn't figure out any sensible solution.
+Simply banning the declaration would seem to have a ripple effect:
+
+     package A1 is
+        type Base is abstract tagged private;
+        procedure P1 (X : Base);
+     private
+        type Base is tagged null record;
+        --procedure P2 (X : Child);
+     end A1;
+
+     package A1.A2 is
+        type Child is new Base with private;
+        procedure P1 (X : Child);
+     private
+        type Child is new Base with null record;
+        --procedure P2 (X : Child);
+     end A1.A2;
+
+     package Some_Other_Pkg is
+        type Ifc is interface;
+        procedure P2 (X : Ifc) is abstract;
+     end Some_Other_Pkg;
+
+     with A1.A2;
+     with Some_Other_Pkg;
+     package A1.A3 is
+        type Grandchild is new A1.A2.Child and Some_Other_Pkg.Ifc with private;
+        procedure P1 (X : Grandchild);
+     private
+        type Grandchild is new A1.A2.Child and Some_Other_Pkg.Ifc
+          with null record;
+        overriding
+        procedure P2 (X : Grandchild);
+     end A1.A3;
+
+This is legal; the overriding routine fufills the "shall be overridden"
+requirement.
+
+Now, imagine that A1 is something like Claw. And A3 is a user-written extension
+of Claw. And the author of Claw decided to add the commented out P2s to the
+private part of Claw. Having done that, unlucky routines like A1.A3 would
+suddenly become illegal, even though nothing will have changed in the visible
+part of Claw.
+
+We can *almost* accept this, if we decide that making something a child of Claw
+effectively makes it part of the subsystem, so dependence on the private part is
+part of that. But it does seem to make interfaces less useful.
+
+So I'm torn between making this rare case illegal (but there is no effective
+workaround short of changing the name or profile of the routine in the interface
+-- this is supposed to be a separate routine from the one in the private part)
+or giving up on the AI. I don't really have a problem with this being illegal,
+since it is effectively exporting routines from the parent's private part --
+something we really don't want to do (especially this way).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, March 16, 2011  7:48 PM
+
+I will do other homework first.  As far as interfaces, they may not seem that
+useful at first, but trust me, once you start getting familiar with them, they
+begin to proliferate.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 16, 2011  8:14 PM
+
+> I will do other homework first.
+
+Yes, please.
+
+You can tell from my message that my opinion on this one flops around like a
+fish caught in a gill net. :-) So it isn't at all obvious that we want to do
+this. OTOH, I think I've convinced myself that the legality rule is necessary to
+prevent unintentional leakage of private information, and it isn't significantly
+different than the incompatibility that the AI already has (which was deemed to
+be OK).
+
+> As far as interfaces, they may not seem that useful at first, but
+> trust me,
+> once you start getting familiar with them, they begin to proliferate.
+
+I don't think it is very likely that I'll be using them seriously anytime soon,
+because I'd have to spend a man-year implementing them first. ;-) [There are
+advantages and disadvantages to having your own compiler...]
+
+But my experience with Ada OOP to date is that abstract types are only valuable
+when you can share part of the data/implementation. And you can't do that with
+interfaces. The value of the whole signature thing -- in any form -- I don't
+get; I can count the number of cases where it would have been possible in some
+sort of useful way in my real code on one hand. YMMV.
+
+[To expand a bit: if you can't share the data and/or implementation, you end up
+having to declare an overriding for each operation before you can do anything
+with the new concrete type. Usually, the entire type has to be implemented
+before you can do any testing at all. That takes *forever*, and is completely at
+odds with the agile-like development process that I've always used (long before
+someone started making money off of "agile development", BTW)-- if it takes more
+than 1/2 day to get to working code, I get nervous.]
+
+Anyway, this is fairly irrelevant to the question at hand.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, March 16, 2011  8:50 PM
+
+For what it is worth, useful interfaces often have only a small number of
+operations, and are not a burden to implement.  But you can get significant
+benefit from implementing those operations, because now your type can join a
+"club" that makes it more useful.  For example, in model-view-controller GUIs,
+there is often the notion of an "observer."  An observer gets notified when the
+"model" changes.  Typically "observer" is an interface with just a couple of
+operations.  You "register" yourself as an "observer" and wait to be called
+back.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent