CVS difference for ais/ai-00413.txt

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

--- ais/ai-00413.txt	2005/04/13 05:37:23	1.2
+++ ais/ai-00413.txt	2005/10/31 05:18:42	1.3
@@ -174,4 +174,129 @@
 
 !appendix
 
+From: Tucker Taft
+Sent: Monday, February 7, 2005  4:32 PM
+
+Here is my second-to-last AI before the meeting, on
+issues relating to aggregates of a partial view,
+task, or protected type.  I also suggest a rule
+for when a task is activated that is part of an
+object defined by an aggregate or a function call.
+
+I did *not* propose wording for this, because it seems
+so speculative, and deserves at least a vote on intent
+in Paris to justify the effort.
+
+[This is version /01 of the AI - ED]
+
 *************************************************************
+
+From: Erhard Ploedereder
+Sent: Tuesday, February  8, 2005  12:10 PM
+
+My comments on Tuck's as yet unnumbered AI:
+
+1. The RM still lacks a rule for determining the master of the tasks
+   created by partial view aggregates.
+
+2. With the re-established coverage rules in this AI, why is it necessary
+   at all to keyword the situation? I.e.,
+   rather than
+     (private and A,B,C => D)
+   why not
+     (A,B,C => D)   and a semantic rule that says that missing components
+     are default initialized (presuming that the visible components all
+     have been checked as present in the aggregate).
+
+   This would do away with extra syntax (and discussions thereof). It has
+   only one minor(?) flaw, if one considers it as a flaw:
+     () becomes a valid aggregate. (I say, so what. Hardly worse than
+           (private). Parsing issues? not really. Generics issues? possibly. )
+
+   What am I missing?
+
+3. Ceterum censeo in anticipation of actual wording:
+   all this cannot possibly be presented under a
+   syntax called record_aggregate. But we could globally rename
+   to composite_aggregate. Not perfect because of the arrays, but
+   definitely better than record_*.
+
+4. We should air the issue on whether we want aggregates for non-private
+   task and protected types.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, February  8, 2005  2:05 PM
+
+> My comments on Tuck's as yet unnumbered AI:
+
+I think Randy posted it as AI-416 [AI-413, actually - ED]
+
+> 1. The RM still lacks a rule for determining the master of the tasks
+>    created by partial view aggregates.
+
+Are you implying that it would be different than that
+for a "full view" aggregate?  I believe AI-162 was intended
+to specify masters of all sorts of things.
+
+> 2. With the re-established coverage rules in this AI, why is it necessary
+>    at all to keyword the situation? I.e.,
+>    rather than
+>      (private and A,B,C => D)
+>    why not
+>      (A,B,C => D)   and a semantic rule that says that missing components
+>      are default initialized (presuming that the visible components all
+>      have been checked as present in the aggregate).
+
+I think this could be quite misleading, and it introduces
+the issue that you have more or fewer components depending
+on where the aggregate is, which could create real
+maintenance headaches or mysteries.  At least with "private"
+you know that when you move the aggregate into a place that
+has a full view, you need to replace "private" with the specification
+of the previously hidden components.
+
+>    This would do away with extra syntax (and discussions thereof). It has
+>    only one minor(?) flaw, if one considers it as a flaw:
+>      () becomes a valid aggregate. (I say, so what. Hardly worse than
+>            (private). Parsing issues? not really. Generics issues? possibly. )
+>
+>    What am I missing?
+
+I would rather not have partial view aggregates at all, than
+to simply say you ignore the private components.
+
+More importantly, there is some real subtlety about what
+happens with controlled types, in particular, when and if
+the "Initialize" procedure is invoked for an aggregate.
+The AI I wrote indicates that if there is a "private,"
+then Initialize will be invoked. We know that if there
+is not private, as with current aggregates, Initialize is
+*not* invoked for the aggregate. I think the presence of
+"private" or something like it is important to make this
+significant distinction.  (I realize I didn't emphasize
+this in the AI, and I'm sorry.  But figuring out how
+to handle the Initialize procedure was by far the
+hardest part of getting the semantics right, and in fact
+drove the decision to disallow specifying expressions
+for limited components in a partial view aggregate.)
+
+> 3. Ceterum censeo in anticipation of actual wording:
+>    all this cannot possibly be presented under a
+>    syntax called record_aggregate. But we could globally rename
+>    to composite_aggregate. Not perfect because of the arrays, but
+>    definitely better than record_*.
+
+Perhaps "Other aggregates" as the name of the section,
+and "other_aggregate" as the syntactic category.
+
+> 4. We should air the issue on whether we want aggregates for non-private
+>    task and protected types.
+
+I think if we have partial view aggregates of a limited type,
+then we should have task and protected type aggregates as well.
+But I am willing to forego all three.
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent