CVS difference for ais/ai-00262.txt

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

--- ais/ai-00262.txt	2001/02/19 22:53:36	1.3
+++ ais/ai-00262.txt	2001/02/23 20:43:09	1.4
@@ -1629,7 +1629,6 @@
 
 ****************************************************************
 
-
 From: dewar@gnat.com
 Sent: Sunday, February 18, 2001 8:49 AM
 
@@ -1670,6 +1669,33 @@
 
 ****************************************************************
 
+From: dewar@gnat.com
+Sent: Monday, February 19, 2001 5:00 PM
+
+Sure, I understand this, but in my view this is the nice-to-have feature,
+the really essential one is to conveniently enable separated private parts.
+
+For example, we often find that the copyright on the private part is
+completely different from the copyright on the public part, and it
+would really be nice to have two documents (e.g. this happens with
+the RM defined library).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 19, 2001 5:26 PM
+
+Humm. The problem outlined on C.L.A., and which I described, and which we're
+trying to solve in AI-262 is the private package needed by the private part
+problem.
+
+Separated private parts only came up as a possible solution to this problem.
+In my opinion, they are a nice-to-have, while the private package problem
+contorts designs (and essentially makes private packages useless for their
+intended purpose); thus it has a much higher priority in my view.
+
+****************************************************************
+
 From: Randy Brukardt [Randy@RRSoftware.Com]
 Sent: Monday, February 19, 2001 4:39 PM
 
@@ -1728,3 +1754,48 @@
 
 ****************************************************************
 
+From: Michael Yoder
+Sent: Monday, February 19, 2001 4:20 PM
+
+Tucker you wrote:
+
+>Pascal Leroy wrote:
+> > ...
+> > However, I believe we need to be pragmatic here.  Pushing more stuff to the
+> > body is probably sensible, but it is going to take several years to
+> > refine/understand the consequences of this new model.  On the other hand,
+> > let me say it once more, "with private" could work tomorrow (tomorrow
+> in ARG
+> > terms probably means next year, I'm sure we all realize that).
+>
+>I don't think this is a good argument.  I really don't want to
+>add something and then soon thereafter declare it obsolescent.
+
+I absolutely agree.  But I am nervous about this judgment unless we agree
+on what "soon" means, and have strong confidence that we *can* declare it
+obsolescent soon.
+
+
+> > ...
+> > So I guess I am saying that I like Mike Y's proposal:
+> >
+> > > It would be better to do "with private" and then move towards a
+> > > Duffian or Taftian ideal language; if we arrive, "with private" and private
+> > > parts can then be made deprecated features.
+>
+>I really don't like this way of thinking.  We should be convinced
+>that "private with" is useful indefinitely, rather than putting
+>it in as a stop-gap.
+>
+>I see "private with" as serving a different purpose than
+>the "in body" stuff.  It focuses on information hiding and
+>modularization, whereas the "in body" really opens up the
+>possibility for more dynamically constructed systems (similar to
+>the "with type" stuff).
+
+Well, I may have misjudged by imagining that you and Bob were aiming at
+nearly identical endpoints.  I think that in Bob's ideal endpoint it would
+become obsolete.  I'm no longer sure about yours.  If not, it would never
+become a deprecated feature unless Bob converted you.  :-)
+
+****************************************************************

Questions? Ask the ACAA Technical Agent