CVS difference for ais/ai-20218.txt

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

--- ais/ai-20218.txt	2003/06/07 03:09:14	1.1
+++ ais/ai-20218.txt	2003/06/07 04:59:00	1.2
@@ -676,4 +676,125 @@
 
 *************************************************************
 
+From: Randy Brukardt
+Sent: Friday, June 6, 2003 10:09 PM
+
+[Editor's note: This is version /01 of the AI.]
+
+Attached is alternative 3 of AI-218. This alternative approach grew out of
+private discussions between John, Pascal, and I over John's drafts of
+alternative 2 of AI-218.
+
+It's clear that being able to write:
+
+    overriding
+    procedure Finalize (Obj : in out T);
+
+is the meat of the proposal. Simply having the compiler tell you when this
+does not override will eliminate a lot of bugs (and debugging sessions).
+Everything else in the proposal is the broccoli. (I know that the cliche is
+"gravy", but broccoli seems more appropriate, because if its on your plate
+you eat it, because you think its good for you. Whether it really is, or
+whether it's edible at all, isn't always clear.)
+
+Anyway, it possible to eliminate a lot of the broccoli with a few simple
+(but radical) changes:
+
+First, we get rid of "overriding or not" or "maybe overriding" or "optional
+overriding" or "ignore overriding" or whatever it is called today. Rather,
+we replace it by "not overriding", which is applied to routines that want to
+declare to be, umm, not overriding. Declarations with this modifier are
+flagged if in fact they are overriding.
+
+Second, we change the checking to occur at the point of the modifier, using
+the state of overriding at that point. This eliminates the leakage of
+privateness that Pascal was concerned about in our private conversations.
+The overriding check does not take into account any overriding that might be
+happening later (in the private part or body).
+
+Third, we revert the default to Ada 95 rules. This eliminates most of the
+reasons for treating generics differently than other units; don't care now
+becomes "say nothing", which seems most appropriate. If you do say
+something, you get appropriate checking.
+
+These changes eliminate any need for a configuration pragma, although it
+still might be a useful idea. With these changes, it is essentially a
+programmer style issue whether or not to use the indicators, and I'd expect
+coding rules (and reviews) and style checkers to enforce them. Pascal had
+suggested that the pragma be a Restriction, as that can look through
+generics and privateness, which does help some. But the problem with the
+pragma is how to handle generics. You pretty much have to use different
+rules in generics than in the rest of the program for this, but the rules to
+use depend a lot on the organization's coding style.
+
+Still, there might be benefit in standardizing such a pragma. The nice thing
+about this alternative is that the pragma is completely separate from the
+meat of the proposal, and many of the nasty problems are with the pragma and
+its checking. If we can't solve those problems, we can simply forget the
+pragma and move on.
+
+I wrote a description of some of these issues in the !discussion section,
+but for this alternative, I dropped the pragma altogether.
+
+I also did a through analysis of the implicit contract issue, and came to a
+rather surprising conclusion.
+
+I did retain John's restrictions on the use of the overriding_clause, and
+tried to justify them. But it might make more sense to drop most of them.
+(Note that John's !discussion seems to assume that there are no such
+restrictions, but his wording makes it clear that there are several
+important ones. At least two examples he gives are illegal by his wording.)
+
+Comments welcome.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Friday, June 6, 2003 10:47 PM
+
+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.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 6, 2003 11:48 PM
+
+We started without them. The primary goal was to have subprogram declarations
+marked "overriding" (using the current syntax) if and only if they are
+overriding operations.
+
+That has two benefits: one is the compile-time checking for errors (in both
+directions), and the other is increased readability (next year, you'll know
+whether "Add_Key" is overriding without having to page through a bunch of specs
+looking for "Add_Key" declarations).
+
+The "only if" seems trivial; it's an error if the keyword is given and the
+operation isn't overriding.
+
+The "if" is messier; it can't be done compatibly with Ada 95. So we started
+with a configuration pragma which required anything not marked to be not
+overridding, which works well for the simple cases.
+
+But both parts start having problems with private types (because the overriding
+situation can be different for the partial and full views, and you don't want
+to mandate breaking privateness). And also with generics (because they often
+are a don't care situation, where you really don't want to check).
+
+By replacing the configuration pragma by "not overriding", we at least get rid
+of most of the generic problems and eliminate the privacy breaking. And then a
+Restriction is about the right model for insuring the "if and only if".
+
+But I suppose we could give up on the original goal instead. If we only add the
+keyword, then it cannot be used in all cases (because there would be no way to
+handle a variety of private type cases - a number of them are given in the
+discussion of the most recent AI), so we couldn't have a language-defined way
+to implement the "if". Of course, an organization could still have coding
+standards that would go most of the way.
+
+*************************************************************
+
+
 

Questions? Ask the ACAA Technical Agent