CVS difference for ais/ai-20218.txt

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

--- ais/ai-20218.txt	2003/06/07 04:59:00	1.2
+++ ais/ai-20218.txt	2003/06/18 00:12:25	1.3
@@ -796,5 +796,202 @@
+From: Robert I. Eachus
+Sent: Saturday, June 7, 2003 2:08 AM
+Robert Dewar wrote:
+> personally I would take Randy's broccoli argument further and eliminate all of
+> it, and just keep the overriding keyword and that's that (I would still prefer
+> a pragma to the overriding, but I guess that's a lost cause). I really don't
+> see the need for these perfectly horrible "or not" etc constructs.
+I still agree with Robert Dewar that a pair of pragmas is much better
+than kludging up the language.  But I do think that this proposal is a
+huge step forward.  I'd just like to go a bit further and request that
+one example show use of not overriding in the public part and overriding
+in the private part of a package.  Unless people understand that
+particular case, no amount of documentation whether non-reserved words
+or pragmas can help:
+       type Foo is private with null record;
+       not overriding
+       procedure Finalize(Object: in out Foo);
+     private
+       type Foo is new Ada.Finalization.Controlled with null record;
+       overriding
+       procedure Finalize(Object: in out Foo);
+From: Robert Dewar
+Sent: Saturday, June 7, 2003  8:59 AM
+I think you need to hang a big sign up in the ARG room saying KISS :-)
+To me, this is a perfect example of a simple useful idea being cluttered up
+with rubbish.
+I would go JUST with the overriding keyword and be done with it (well as you
+know I would use a pragma to ease transition, but that's another issue, and
+I can live with the keyword).
+Now if you think it is useful to have a mode in which you get warnings or
+errors if the keyword is not used, that's a typical style issue that should be
+addressed by the implementation. Certainly it would be reasonable to have a
+warning when the keyword is not used when the subprogram does override, but I
+am not sure that we need language gizmos for that. If we start putting in
+language gizmos for this sort of style issue, things will definitely get
+From: Robert I. Eachus
+Sent: Saturday, June 7, 2003 10:00 AM
+Robert Dewar wrote:
+> I would go JUST with the overriding keyword and be done with it (well as you
+> know I would use a pragma to ease transition, but that's another issue, and
+> I can live with the keyword).
+I don't want to seem like Robert Dewar and I are in a tag team match,
+but it is clear that on this AI we are trying to keep our eye on the
+same objectives.
+What are we trying to do here?  We are trying to make it possible for
+programmers to "comment" their code in a way that the compiler will
+verify. This particular feature is neeeded, I might even agree to
+necessary, in two situations:
+1. A programmer is not sure whether or not a particular subprogram is
+overriding.  (And possibly where it is overriding, or non-overriding.)
+In these cases a programmer will use the pragma  or non-reserved word as
+an assertion.  If his understanding of the language, or the program, is
+wrong, the compiler will tell him so.
+2. The programmer knows what the rules are, and that this is a
+particularly tricky case.  He wants to document for maintenance purpose
+exactly what is going on--and probably that his code depends on it.
+When we look at these cases, some things stand out.  First any subtle
+rules about where 'overriding' or the pragma can occur are
+counterproductive.  The programmer doesn't care that some group of
+language experts thought that this case was too tricky, or that
+"everyone knows" that overloading can't occur in this case, so that the
+keyword shouldn't be allowed.  From the programmer's point of view, the
+purpose of this feature is documentation, and anything that gets in the
+way of using it for that is counterproductive.
+This is why I get nervous about such wonderful "features" of the keyword
+approach as requiring a duplicate declaration just to hang the keyword
+on, or not allowing the keyword on subprogram bodies.  If it is
+documentation, I want to use it on generic instantiations and even on
+renamings of entries, or for that matter on entries themselves.  I
+especially want to be able to use it twice in the case that some
+subprogram is not overriding in the visible part, but is overriding in
+the private part, or in the body.
+In fact, from my point of view, subprograms that are overriding in the
+private part of a child package but not in the private part of a
+non-child package are one of the most important cases for documentation.
+It may look to the maintenance programmer that making this a separate
+unit, or instantiating this generic as a child unit changes nothing.
+But it may not work, and the programmer should be able to use this
+feature to warn maintaniners.  A similar argument applied to a with
+clause on a body whose only effect is to make some subprograms overriding.
+Also, requiring an extra declaration of a subprogram just so that the
+keyword can be put in the 'right' place is to me a major disadvantage of
+the keyword approach.  It requires programmers to learn a new language
+feature just to cover an odd corner case.  The problem is that, in most
+cases, the result will be that the keyword is not used, because the
+programmer doesn't know how to use the special language feature.  The
+corner case for the pragma approach is one that I find much less
+troubling.  When someone doesn't know how to use the pragma placement
+rules to get the intended effect runs into a problem, what will he do?
+Probably use a different name for the non-overriding homograph.  I just
+don't see that as a problem.
+From: Robert Dewar
+Sent: Saturday, June 7, 2003  10:29 AM
+Actually I have a bit of a different view from Robert Eachus. I don't
+see the point of allowing programmers who know what is going on to
+document things in a compiler checked way. Or more accurately, that
+is great to document all sorts of things, but why pick out this one.
+The use of the keyword to me seems to be the following.
+I write an overriding declaration. I want to make sure it overrides, so
+I use the keyword. That way I get warned if I have misspelled the
+spec, or if I misunderstand the rules.
+Going much beyond this seems overkill to me.
+I must say that we have very seldom seen customers get into trouble on
+this issue, and in the few cases that has happened, the very simple
+approach would have been more than adequate.
+I think we are gearing up the big cannons to fire at an enemy who barely
+exists here.
+From: Tucker Taft
+Sent: Saturday, June 7, 2003  3:49 PM
+Thanks for writing this up, Randy.
+I like just having "overriding" and "not overriding."
+The "maybe overriding" was just too weird.
+I agree with the idea of putting the configuration pragma in
+a separate AI, making it clear that it is added value
+(or subtracted value ;-), but not essential to the
+basic proposal.
+The one thing that makes me uncomfortable is the
+rule where you say it is ignored in a generic declaration.  That
+seems strange to me, and not justified in the examples
+I can construct.  By and large, Ada doesn't care what kinds
+of overloading or overriding occurs in generic instances,
+but generic declarations are handled like non-generic
+declarations.  You seem to be inverting this, where the
+*only* checking is in the instance.  *Requiring* overriding
+in the instance seems positively weird, and a whole new
+concept.  Can you construct an example where this would
+actually be desirable?
+So I like your proposal in general, but I would push
+for either:
+    1) Overriding and not overriding apply in both the
+          generic decl and the instance (my mild preference);
+  or
+    2) Overriding and not overriding applies only in the
+          generic decl.
+You have proposed they apply *only* in the instance,
+and I don't think this is consistent with any other
+rule in the language, and I haven't been able to construct
+realistic and important examples where this rule would be
+sufficiently preferable to justify this inconsistent,
+one-of-a-kind rule.
+I don't see the "not overriding" as part of the "broccoli".
+It seems clear to me that if we provide an explicit
+"overriding" keyword, with the default being
+"either," then programmers will clearly preceive a hole
+in the language if we don't also provide "not overriding."

Questions? Ask the ACAA Technical Agent