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

--- ai05s/ai05-0247-1.txt	2011/08/17 00:24:13	1.14
+++ ai05s/ai05-0247-1.txt	2012/01/26 07:54:45	1.15
@@ -8034,7 +8034,182 @@
 
 ****************************************************************
 
+From: Jean-Pierre Rosen
+Sent: Thursday, April  7, 2011  6:52 PM
+
+(Sorry for leaving the meeting early: I got disconnected, and Tracey didn't
+answer when I tried to reconnect)
+
+I (and some others apparently) think that it should be visible if a precondition
+is "ored" with preconditions from the progenitors. The current syntax (with
+Pre'class => <Expression>) would be allowed only for root types (tagged or
+interfaces).
+
+I guess it would not be allowed to specify Pre'class unless all progenitors also
+have Pre'class specified. (if at least one progenitor has no precondition, this
+ruins all further preconditions).
+
+Here are some possibilities that were discussed:
+
+with Pre'Class => else <expression>      -- 1
+with Pre'Class => or [else] <expression> -- 2
+with Pre'Class => T1'Pre'Class or I1'Pre'Class or <expression> -- 3
+with Pre'Class => <expr1> or <expr2> or <expression> -- 4
+with Alternative_Pre'Class => <expression> -- 5
+
+1: reads ugly, but is as close as we can get to Eiffel
+
+2: reads slightly better, and allows the user to choose between "or" and "or
+   else" (I don't know if there is value in that)
+
+3: T1'Pre'Class etc refer to the preconditions of T1 etc. It would be required
+   to mention all inherited preconditions. Slightly verbose.
+
+4: Like 3, except that statically matching expressions are used in place of
+   special attributes. The most explicit for the reader, but highly verbose.
+
+5: Just use a different aspect for non-root types. Maybe the simplest thing to
+   do, but does not draw attention of the reader as much as the other ones.
+
+Other ideas welcome.
+
+****************************************************************
+
 From: Randy Brukardt
+Sent: Thursday, April  7, 2011  10:33 PM
+
+> (Sorry for leaving the meeting early: I got disconnected, and Tracey
+> didn't answer when I tried to reconnect)
+
+I don't think we noticed; the obvious problem with considering silence as a
+positive vote. When were you cut off? I wonder how many AIs that you were
+recorded as having voted for.
+
+> I (and some others apparently) think that it should be visible if a
+> precondition is "ored" with preconditions from the progenitors. The
+> current syntax (with Pre'class =>
+> <Expression>) would be allowed only for root types (tagged or
+> interfaces).
+
+It's not the type so much as the operation. It doesn't matter for what type the
+operation is declared, but that there is no inherited operations. Thus, it
+should only be allowed on root *operations*, that is those that should have the
+"not overriding" keyword.
+
+> I guess it would not be allowed to specify Pre'class unless all
+> progenitors also have Pre'class specified. (if at least one progenitor
+> has no precondition, this ruins all further preconditions).
+
+There is no such concept anymore; all tagged primitive operations have
+Pre'Class. It has the value of True if not inherited or specified. But I
+understand your point; if someone inherits "True", there isn't much point in
+allowing further specification of the class-wide precondition because it cannot
+have any effect (ignoring side-effects, which aren't promised to happen anyway).
+It's almost certainly a mistake (with the exception if it is also "True").
+
+> Here are some possibilities that were discussed:
+
+These got scrambled, I unscrambled them.
+
+> with Pre'Class => else <expression>      -- 1
+
+> with Pre'Class => or [else] <expression> -- 2
+
+> with Pre'Class => T1'Pre'Class or I1'Pre'Class or <expression> -- 3
+
+> with Pre'Class => <expr1> or <expr2> or <expression> -- 4
+
+> with Alternative_Pre'Class => <expression> -- 5
+
+> 1: reads ugly, but is as close as we can get to Eiffel
+>
+> 2: reads slightly better, and allows the user to choose between "or"
+> and "or else" (I don't know if there is value in that)
+
+I think it is currently defined that it can be short circuited; since there
+shouldn't be side-effects in a "good" precondition, it can't matter much.
+
+> 3: T1'Pre'Class etc refer to the preconditions of T1 etc. It would be
+> required to mention all inherited preconditions.
+> Slightly verbose.
+
+Somewhat of an understatement, if the type names are long enough.
+
+> 4: Like 3, except that statically matching expressions are used in
+> place of special attributes. The most explicit for the reader, but
+> highly verbose.
+
+Yup.
+
+> 5: Just use a different aspect for non-root types. Maybe the simplest
+> thing to do, but does not draw attention of the reader as much as the
+> other ones.
+
+That depends on the name. It needs to be good. "Weaker_Pre'Class"?
+"Weakened_Pre'Class"?
+
+"Only_OOP_Experts_Will_Ever_Use_This_Weaker_Precondition_Possibility'Class"?
+;-)
+
+> Other ideas welcome.
+
+See above.
+
+Note that Bob had another question, which was whether specifying this syntax
+(whatever it is) is required when multiple inheritance occurs even if there is
+no new precondition. I think that has to be part of the rules. It can be
+annoying (as you'd probably have to repeat one of the inherited preconditions),
+but I still think that this will be rare enough that it needs a flag in the code
+to show that something unusual is going on.
+
+(I realize that just outright banning it is not going to fly, although that has
+always been my preferencee.)
+
+Note that this is exactly the same case as we are requiring overriding, so the
+rule can piggyback on that one.
+
+At this point, I'm in favor of (1), simply because it is the least verbose while
+still providing the obvious key that this is not the usual case of defining a
+new stand-alone precondition for a new class of operations. This is not likely
+to be very common, so I don't much care if it is ugly.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, April  8, 2011  12:58 AM
+
+> Note that Bob had another question, which was whether specifying this
+> syntax (whatever it is) is required when multiple inheritance occurs
+> even if there is no new precondition. I think that has to be part of
+> the rules. It can be annoying (as you'd probably have to repeat one of
+> the inherited preconditions), but I still think that this will be rare
+> enough that it needs a flag in the code to show that something unusual is going on.
+
+You don't have to repeat anything, just specify "else false". Hmm, I guess
+someone won't find this especially pretty.
+
+The alternative would be that if no new precondition is specified, there is an
+implicit "else false". I don't mind this way: if your implementation is subject
+to *more* preconditions than you thought, it cannot harm. But it has the strange
+implication that if you don't specify a precondition, the implicit one is True
+for root operations, and False for overriding operations. Well, we could say
+that the root operation inherits a True precondition, to which the implicit
+"else false" is added.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, April  8, 2011  1:07 AM
+
+You are right, it isn't that severe of a problem. Perhaps we don't need to solve
+it.
+
+The idea of "else False" being the default actually makes too much sense. I like
+it. My guess is that the other guys will hate it. ;-)
+
+****************************************************************
+
+From: Randy Brukardt
 Sent: Thursday, April  7, 2011  9:58 PM
 
 During today's phone call, it was pointed out that the title of Section 13
@@ -8223,11 +8398,6 @@
 
 ****************************************************************
 
-From: John Barnes
-Sent: Monday, April 11, 2011  1:12 PM
-
-****************************************************************
-
 From: Robert Dewar
 Sent: Monday, April 11, 2011  1:12 PM
 
@@ -8519,13 +8689,15 @@
 From: Tucker Taft
 Sent: Sunday, May 1, 2011 11:36 AM
 
-I have been out of town, at the Penn Relays (a truly amazing track meet -- 45,000
-people in the stands screaming at the top of their lungs for people running track!?).
+I have been out of town, at the Penn Relays (a truly amazing track meet --
+45,000 people in the stands screaming at the top of their lungs for people
+running track!?).
+
+I thought we could convert chapter 13 into a general chapter on "Program
+Annotation" but that didn't seem to garner much interest.  Failing that, I am
+happy to follow along with the general consensus on where to locate
+pre/postconditions.
 
-I thought we could convert chapter 13 into a general chapter on "Program Annotation"
-but that didn't seem to garner much interest.  Failing that, I am happy to follow
-along with the general consensus on where to locate pre/postconditions.
-
 ****************************************************************
 
 From: Brad Moore
@@ -8533,7 +8705,7 @@
 
 [Appropriate part of a large message - Editor.]
 
-> AI05-0247-1/09  Preconditions, Postconditions, multiple inheritance, 
+> AI05-0247-1/09  Preconditions, Postconditions, multiple inheritance,
 > and dispatching calls
 >     [Changes as discussed during the phone meeting: Added rules to require overriding
 >     for inherited routines which would either violate LSP or have unenforced preconditions;
@@ -8544,7 +8716,7 @@
 
 Editorial Comment: In the problem section, T2'Class should be I2'Class.
 
-Editorial Comment: Legality Rules, 2nd Para. "If a type has a inherited" 
+Editorial Comment: Legality Rules, 2nd Para. "If a type has a inherited"
 => "If a type has an inheritied"
 
 ****************************************************************
@@ -8661,15 +8833,5 @@
    For a call via an access-to-subprogram value, all precondition and postcondition
    checks performed are determined by the subprogram or entry denoted by the prefix of the
    Access attribute reference that produced the value.
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Saturday, June 25, 2011  3:43 AM
-
-****************************************************************
-
-From: Tucker Taft
-Sent: Saturday, June 25, 2011  3:43 AM
 
 ****************************************************************