CVS difference for ais/ai-00251.txt

Differences between 1.9 and version 1.10
Log of other versions for file ais/ai-00251.txt

--- ais/ai-00251.txt	2002/10/01 03:08:54	1.9
+++ ais/ai-00251.txt	2003/01/03 00:01:35	1.10
@@ -2279,3 +2279,302 @@
 
 ****************************************************************
 
+From: Michael F. Yoder
+Sent: Thursday, October 24, 2002  9:05 AM
+
+We can get the benefit of Eiffel's renamings, but without awful syntax,
+if we allow interface renamings to tweak things in a manner similar to
+procedure renamings changing parameter names.  Something like:
+
+   interface T2 renames T1 is
+      procedure Name_Collision_On_P (args) renames P;
+      function Oops_F_Has_Homonyms (args) return blah renames F;
+   end interface;
+
+Then, change the rule so that homonyms from different interfaces are
+always illegal. If the user wants to complete two or more homonyms the
+same way, she can use renamings-as-bodies to complete those she's forced
+to rename.
+
+****************************************************************
+
+From: Michael F. Yoder
+Sent: Thursday, October 24, 2002  9:31 AM
+
+Sorry, I didn't include enough context for this to make sense to those
+who didn't happen to be at the last meeting. The context is that a
+tagged type is inheriting from two or more interfaces that have
+homonyms, so the effect of blending them together isn't clear. There are
+two cases:
+
+(1) The homonyms aren't all mode-conformant to one another: one body
+can't complete all of them.
+(2) The homonyms are all mode-conformant, so completing them all is at
+least possible.
+
+There's probably uses for this ability other than avoiding name
+collisions, e.g.:
+
+   interface Sunviews_Style_Interface renames X_Style_Interface is...
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, October 24, 2002  9:33 AM
+
+I see that you believe that the proposal is not complex enough already ;-)
+
+I mean, this AI is already extremely complicated, both from the language
+design standpoint and from the implementation standpoint.  So complex in
+fact that I doubt if it will make it into the final amendment.  And even if
+it does, speaking with my implementer hat, I have a hard time believing that
+we will make the vast investment needed to support it in our products (do I
+sound like Robert?).
+
+So I think we should strive to simplify the proposal, not add bells and
+whistles that solve cornercase issues.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, October 24, 2002  10:03 AM
+
+I agree that this proposal is way past the complexit threshhold. I don't
+know if it will make it into the amendment, but I can be pretty sure
+that folks at ACT are not going to give this one any attention regardless.
+
+The danger of course is that if we get piles of proposals of this kind,
+then a strong argument can and will be made to leave the whole thing
+alone rather than rock the boat with over-complex stuff.
+
+****************************************************************
+
+From: Michael F. Yoder
+Sent: Thursday, October 24, 2002  1:21 PM
+
+>>I see that you believe that the proposal is not complex enough already
+
+I thought the proposal was horridly complex also until I sorted through
+what it actually meant. Also, much apparent complexity came from keeping
+multiple variations in mind at the same time, only one of which can
+actually be used for a final proposal.
+
+I'm not a big OOP fan, but having a halfway-house technology gets the
+worst of both worlds: OOP advocates will sniff at it, but you still have
+the maintenance costs. If that sounds like a "keeping up with Java"
+argument, well, it probably *is* that sort of an argument. I think
+exception types fall into the same category.
+
+The one instance where I might disagree with Tucker is that I'd prefer
+that the line between the classes having treeish inclusion and the
+others (the interfaces) be kept visible, and I would cheerfully buy
+simplicity by making it more visible.
+
+Oh, and finally, I don't expect the issue to be a cornercase issue in
+practice unless interfaces just aren't used. If it were a cornercase
+issue, why would the awful syntax of Eiffel's renaming conventions (for
+solving this problem) ever occur? But perhaps Bob Duff can elaborate
+about the circumstances in which he saw these things.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, October 24, 2002  1:33 PM
+
+I think this is much more important for Eiffel
+because they use inheritance for *everything*
+(including with/use clauses).  Note that Java
+has no renaming capability, and they are succeeding
+hansomely.  Also, Eiffel has multiple *implementation*
+inheritance, whereas our proposal is a better fit for
+Java, which has multiple *interface* inheritance.
+In Eiffel, you have *code* that you are inheriting
+potentially from two places, and perhaps that means you
+more frequently will need to resolve conflicts.  With the proposed
+interfaces, no code is being inherited, which might
+simplify doing "renaming by editing" ;-).
+
+My bottom line is I really don't think renaming
+is important to making this useful, and Java
+is my best evidence.  In Ada, we get to use
+result type and defaulted parameters to distinguish
+as well, whereas in Java, they don't have that
+flexibility.  (Using defaulted but ignored parameters
+to distinguish things might be a clever hack around
+name conflicts, for those who really find them serious.)
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, October 24, 2002  3:57 PM
+
+> But perhaps Bob Duff can elaborate
+> about the circumstances in which he saw these things.
+
+I now believe that the name-clash problem should not be solved.
+(I argued the opposite at the meeting, but Tucker's speech on the
+subject convinced me to change my mind.)
+
+I think this interfaces AI and the other AI about type stubs are the two
+most important AI's on the table.  People really do choose other
+languages over Ada because of these two major issues.  My evidence is of
+course anecdotal, as is nearly all evidence in the so-called "science"
+of Computer Science.  I have not done market surveys and the like.
+Sigh.
+
+I don't much care whether these two features make it into the Amendment,
+but I think it's important to the long-term success of Ada that they get
+implemented by the major compiler vendors, and in a uniform fashion (the
+"uniform" part is what standards are all about!).
+
+It worries me when I see Robert and Pascal threatening to not implement
+these.  (I do understand the reasons.  SofCheck doesn't have tons of
+funding to do this sort of thing, either, unfortunately.)
+
+The "problem" we're discussing is that if you import two interfaces, and
+get a name clash, you can get "stuck".  But the *usual* way to fix the
+problem is to go edit the source code of one or both interfaces --
+change the names so they don't clash.  The only time that won't work is
+when you're importing two libraries, and you can't (or don't want to)
+change their source.
+
+The "problem" can only occur if the interfaces proposal is a great
+success (widely implemented, and used by many vendors).  So I say:
+let's solve that problem when it happens.  I.e. consider any "renaming"
+bells and whistles as a totally separate AI from the basic interfaces
+proposal.  There is no technical reason to solve the problem *now*.
+
+I say, let's agree on a standard for the interfaces thing, and let's
+implement it in the various compilers.  If and when Ada becomes wildly
+successful, we can worry about the naming-clash problem.
+
+Other points:
+
+    - The naming clash problem really is a corner case: You have to have
+      two independent developers choose the same name, the same number
+      and types of parameters, the same result type, AND DIFFERENT
+      MODES.
+
+    - Any solution to the "problem" that I can think of is totally
+      independent from the basic interfaces proposal -- so there's no
+      reason to include it now.  As they say, let's burn that bridge
+      when we come to it.
+
+    - The interfaces proposal should be kept as simple as possible, so
+      that vendors may find it feasible to implement on limited
+      budgets.
+
+    - Java doesn't address the "problem", and does just fine.
+
+    - I don't agree with Mike that OOP advocates will "sniff at" the
+      interfaces stuff without a solution to the naming clash problem.
+
+For all these reasons, I am opposed to solving the naming clash problem
+as part of this AI.  There's no harm in creating another AI to address
+the problem, but *that* AI should be voted in 2015 or so.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, October 24, 2002  4:15 PM
+
+> I thought the proposal was horridly complex also until I sorted through
+> what it actually meant. Also, much apparent complexity came from keeping
+> multiple variations in mind at the same time, only one of which can
+> actually be used for a final proposal.
+
+I agree with that.  The proposal represents non-trivial implementation
+effort, but it's not *that* bad.  It always seems worse when you're
+weighing 17 possible solutions to the same problem.
+
+But I still say: let's keep it as simple as possible.
+(But no simpler.  ;-))
+
+****************************************************************
+
+From: Michael F. Yoder
+Sent: Thursday, October 24, 2002  6:11 PM
+
+>- I don't agree with Mike that OOP advocates will "sniff at" the
+>      interfaces stuff without a solution to the naming clash problem.
+
+Just to set the record straight, I didn't say that; this is combining a
+phrase into a different context. What I believe is that OOP advocates
+will sniff at Ada if it has no multiple-inheritance mechanism that they
+choose to regard as real. (There doesn't seem to be much enthusiasm for
+the generic mixin mechanism et al., and I don't entirely blame them.)
+Java seems to have established interfaces as real, and they don't break
+the good properties (e.g. time-boundedness) of the single-inheritance
+model, at least not for operations on the treeish classes.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, October 24, 2002  7:20 PM
+
+Hmmm, this seems dubious to me. Why do you believe this?
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, October 24, 2002  4:15 PM
+
+> Robert A Duff wrote:
+>
+> >- I don't agree with Mike that OOP advocates will "sniff at" the
+> >      interfaces stuff without a solution to the naming clash problem.
+> >
+> Just to set the record straight, I didn't say that; this is combining a
+> phrase into a different context.
+
+Sorry if I misquoted you.
+
+>... What I believe is that OOP advocates
+> will sniff at Ada if it has no multiple-inheritance mechanism that they
+> choose to regard as real. (There doesn't seem to be much enthusiasm for
+> the generic mixin mechanism et al., and I don't entirely blame them.)
+> Java seems to have established interfaces as real, and they don't break
+> the good properties (e.g. time-boundedness) of the single-inheritance
+> model, at least not for operations on the treeish classes.
+
+I agree with that.  So the question is, will the lack of a solution to
+the naming clash problem cause folks to scorn our multiple-inheritance
+of interfaces solution?  I think not.
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Thursday, October 24, 2002  7:50 PM
+
+>I now believe that the name-clash problem should not be solved.
+>(I argued the opposite at the meeting, but Tucker's speech on the
+>subject convinced me to change my mind.)
+
+I think the problem is actually a bit larger than you think, but I don't
+think that it is anything that the ARG, or WG9 can or should solve.
+There are many cases where existing languages will see a clash and Ada
+won't.  Great.  There is one case where Ada in my opinion should see a
+problem and alert the user at compile time.  For example, let's say you
+are inheriting from two different container types.  One has an Append
+with an in out parameter, the parameter of the other is mode in.  Forget
+for a moment all the philosophical and design issues which could result
+in choosing one or the other.  There is a design problem here, and the
+right thing for the compiler to do is to tell the user, not paper it
+over.  If the user concludes that the two interfaces are not compatible?
+He is right.  There are ugly workarounds, but they should be ugly.
+
+The other case that hasn't been discussed as much, but has been
+mentioned.  It is where you have say two Append procedures, one with a
+single parameter and one that adds a position parameter with a default.
+ It is possible to inherit from both interfaces, but the only way to
+actually call the one parameter version is to rename it.  This is
+currently one of the more unexpected ;-) features of Ada when it pops
+up. But again there is no reason the ARG should try to "fix" anything.
+If through generic instantiation and/or use clauses a call becomes
+ambiguous for this reason, the programmer has to do real work to decide
+between calls which should go to the one parameter version, and calls
+which should use the default.  Shrug.   The compiler can only alert the
+programmer to potential problems, it can't read his mind.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent