CVS difference for ais/ai-30217.txt

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

--- ais/ai-30217.txt	2002/02/07 04:56:43	1.1
+++ ais/ai-30217.txt	2002/02/20 01:04:09	1.2
@@ -682,3 +682,771 @@
 
 *************************************************************
 
+From: Tucker Taft
+Sent: Thursday, February 7, 2002,  5:42 AM
+
+I think there are two kinds of checks (at least) relevant to ai-217-04:
+
+1) A use of the stub name, or a dereference of an access-to-stub;
+     should it be considered incomplete or not?
+
+2) A matching between a non-incomplete type, and a stub name that
+    according to (1) would be considered incomplete;
+    do they match?
+
+For (1) I would propose that we have fairly rigid rules, in particular
+that the package (or a library package renaming thereof) identifed
+by the library package "specifier" given in the type stub declaration
+be enclosing the current place, or be mentioned in a with clause that
+applies to the current place.  [I would require that the specifier be
+the full expanded, no-renames-allowed, name of the package, by the way.]
+
+For (2) I would be very liberal.  If the name of the package containing
+the non-incomplete type declaration matches the package specifier of
+the stub, then the two types match.
+
+The key difference here is that once you have a non-incomplete type,
+it can "pull" other type stubs into completeness where it must
+"match" them.  However, if you have a reference to a type stub
+in a fairly stand-alone way, it requires that the specified package
+be "with"ed or enclosing at the place of the (de)reference.
+This prevents "ripple" effects due to "distant" semantic dependences
+on the completing type.
+
+For example:
+    X : <type_stub>;  -- legal only if completing
+                      -- package withed/enclosing
+
+    Y : access-to-stub;
+    Q : Integer := Y.all.F1;  -- legal only if completing package
+                              -- withed/enclosing
+
+In contrast:
+    Z : <completing_type> := Y.all;  -- Legal even if completing package
+                                     -- not withed/enclosing
+
+This means that deciding whether Y.all is legal means waiting for
+overload resolution to complete.  During overload resolution,
+if the expected type is a type-stub (that isn't completed by (1))
+and the name or expression is the completing type, or vice-versa,
+the resolution will proceed, treating the type-stub as the
+completing type.  On the other hand, two distinct type-stubs which
+happen to have the same completing type don't match.
+
+One important example of something which I presume is *not* legal is the
+following:
+
+     package S is
+          type T is tagged separate in P;
+          procedure Print(X : T);
+          type Acc_T is access T;
+     end S;
+
+     with S;
+     procedure Proc(Y : S.Acc_T) is
+     begin
+          S.Print(Y.all);  -- illegal use of incomplete type
+     end Proc;
+
+In the above, I suggest you would have to add a "with P;" to procedure
+Proc to make it legal. (I think... ;-)
+
+In general, we probably need a number of concrete examples of both
+legal and illegal uses to make sure we have rules that we can
+all accept, and the "average" user will find palatable as well.
+Arguing these entirely in the abstract is difficult, and often
+misleading.
+
+-------------------------
+
+As a side note, I certainly agree with Randy that we should
+allow the completing type to be a private type or extension.
+I suspect it was just miswording that had disallowed this.
+
+Also, I think it is important that we introduce the new concept
+of "tagged incomplete types" in general, and then use that concept
+here.  Hence "type T is tagged;" would be legal in general,
+and its main advantage is use as formal parameters and with 'Class.
+Introducing these capabilities only as part of type stubs would
+seem more confusing and clearly less flexible.
+
+*************************************************************
+
+From: Erhard Ploedereder
+Sent: Thursday, February 7, 2002,  7:50 AM
+
+>>The completing type declaration must be a full type declaration in the
+
+> Humm, this would prevent completing with a private type, which has to be
+> allowed. (It is not at full type in the visible part of the package!!) Your
+
+Unintentional. It should say non-incomplete type declaration.
+
+*************************************************************
+
+From: Erhard Ploedereder
+Sent: Thursday, February 7, 2002, 10:03 AM
+
+The "operational" model that I had in mind with the "check-as-needed"
+model is the following:
+
+Use of a stub name or access-to-stub is a-priori considered use of an
+incomplete type. (Normal visibility rules apply, of course.)
+
+If the usage is legal for an incomplete type or access-to-incomplete, no
+further check happens.
+
+If the usage is not legal, then the completion check is performed and, if
+successful, the usage is checked by the rules that apply for the completed
+type. The usage may, but need not, imply visibility of the completing type
+declaration -- the usual rules for visibility of operations apply.
+
+A possible restriction that I mulled over was to say that usage of the
+separate incomplete type is restricted entirely to the package that
+declares the stub. That's worth debating.
+
+> For (1) I would propose that we have fairly rigid rules, in particular
+> that the package (or a library package renaming thereof) identifed
+> by the library package "specifier" given in the type stub declaration
+> be enclosing the current place, or be mentioned in a with clause that
+> applies to the current place.
+
+But doesn't this put a compilation order requirement in place ? I don't
+see why this restriction is needed/desirable. And I fear an unnecessary
+restriction arising here.
+
+Can you provide a scenario for the ripple effect that you worry about ?
+The one I constructed doesn't seem worrisome, quite the contrary.
+
+On your examples:
+
+    Y : access-to-stub;
+    ...
+
+    Z : <completing_type> := Y.all;  -- Legal even if completing package
+                                     -- not withed/enclosing
+
+I am not sure what you mean by the comment. That this is legal in any case?
+I hope not. The completion check must occur here (or at some prior point).
+
+> This means that deciding whether Y.all is legal means waiting for
+> overload resolution to complete.  During overload resolution,
+> if the expected type is a type-stub (that isn't completed by (1))
+> and the name or expression is the completing type, or vice-versa,
+> the resolution will proceed, treating the type-stub as the
+> completing type.  On the other hand, two distinct type-stubs which
+> happen to have the same completing type don't match.
+
+My model is:
+
+During overload resolution, if the expected type is a type-stub and the name
+or expression is of the completing type, or vice-versa, THE COMPLETION CHECK
+HAPPENS and THEN the resolution will proceed, treating the type-stub as the
+completing type. Two distinct type-stubs which happen to
+have the same completing type DO match. (I think that the last part is
+important!).
+
+------------
+And on.....
+
+     package S is
+          type T is tagged separate in P;
+          procedure Print(X : T);
+          type Acc_T is access T;
+     end S;
+
+     with S;
+     procedure Proc(Y : S.Acc_T) is
+     begin
+          S.Print(Y.all);  -- illegal use of incomplete type
+     end Proc;
+
+> In the above, I suggest you would have to add a "with P;" to procedure
+> Proc to make it legal. (I think... ;-)
+
+As written, I agree :-) But in terms of intent, I would much prefer the
+semantic closure model than the visibility model. It's kind of hard
+to explain why dereferencing normally does not require visibility of
+the type, but merely semantic closure, while this should be
+different for a completing type.
+
+I can be convinced by good examples, though :-) but I have not seen
+one yet. Hence the request for a ripple example that's bad for the user.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 7, 2002, 10:57 AM
+
+I think I understand your model now.  You are saying that
+any use that is illegal for incomplete types would trigger
+an attempt to find the completing type.  There would be
+no requirement to explicitly "with" anything.  It would
+be like the current rules for attributes like 'Address,
+where you end up with an implicit dependence on package System
+if you use 'Address.  Of course in 99 44/100 % of the time,
+you would already have such a dependence.
+
+That seems reasonable, and it is clearly easiest for the user.
+It is probably not worth worrying about the rare cases
+where this is creating an implicit dependence, just
+as we decided it wasn't worth worrying about it for 'Address.
+
+As far as ripple effects, your approach (presuming I understand
+it) eliminates the problem, in the same way that the Ada 95
+approach to 'Address eliminated the problem.  Adding or removing
+a "distant" with clause has no effect on the legality of the
+usage.
+
+This does mean that we need to be careful not to get into a cyclic
+dependence, since we don't have the normal "with" clause processing
+to protect us.
+
+-------------
+Exactly When the Search for the Completion Occurs
+
+Presuming I understand your model, we need to be very clear
+about what sort of usage triggers the search for the completing type --
+Clearly dereferencing an access value.  I suppose any use of
+the stub name (or stub name'Class) other than after the word
+"access" or as a formal parameter (if tagged) would trigger
+the search as well.
+
+Perhaps we should disallow any usage that
+would trigger such a "search" in the compilation unit where
+the type stub itself is defined.  If such a use appeared there,
+that would clearly defeat the purpose of making it a stub.
+Pretty much any place else is a reasonable place to cause
+the search (and the implicit dependence) to occur.
+
+-------------
+Usages of Stub Name Outside the Defining Package?
+
+It is an intriguing idea to disallow usages of the stub name
+outside the defining package.  Of course we want to allow
+usages of the access-to-stub type anywhere.  My fear is
+that disallowing such usages of the stub name might get
+in the way of certain reasonable structures.  On the other
+hand, I suppose there is no particular reason you can't
+just throw in another stub with the same completing type.
+But that might get tedious or confusing, and it wouldn't
+work for library subprograms, where there is no place
+to put the stub declaration (at least there is no place
+to put it if you want to use it as a formal parameter).
+Similarly, it would be difficult to use a type stub
+in the generic formal part, if you disallowed references
+outside the defining package.
+
+Perhaps we should allow stubs to appear anywhere, since
+they are really more like subtypes.  It would only be the
+completing type which would have to be a type declared immediately
+within a library package.  (This begins to make the stub sound
+more like a "with type" again!  Groan ;-)
+
+On balance, even if we choose to allow stubs to appear in many
+contexts, I think we should allow references outside
+the defining package.
+
+-------
+Generics?
+
+By the way, should we allow the completing type to be in a child of a
+generic package, if the stub is in a child of the same generic package?
+Or something like that?  We would need an example, I suppose,
+to show how this whole thing could work with generics.  I'm not
+sure it is that big a deal, since you can accomplish roughly
+the same thing by using a formal type.
+
+*************************************************************
+
+From: Erhard Ploedereder
+Sent: Thursday, February 7, 2002, 12:03 PM
+
+> Also, I think it is important that we introduce the new concept
+> of "tagged incomplete types" in general, and then use that concept
+> here.  Hence "type T is tagged;" would be legal in general,
+> and its main advantage is use as formal parameters and with 'Class.
+
+I agree. (Just didn't want to muddy the separate type issue with this.)
+
+*************************************************************
+
+From: Erhard Ploedereder
+Sent: Thursday, February 7, 2002, 12:41 PM
+
+> I think I understand your model now.  You are saying that
+> any use that is illegal for incomplete types would trigger
+> an attempt to find the completing type.  There would be
+> no requirement to explicitly "with" anything.
+
+Yes.
+
+> It would be like the current rules for attributes like 'Address,
+> where you end up with an implicit dependence on package System
+> if you use 'Address.  Of course in 99 44/100 % of the time,
+> you would already have such a dependence.
+
+I actually believe it's 100% in the sense that my rules require
+the existing dependence (or else the type remains incomplete).
+I am not advocating an implicit dependence to be created, i.e.,
+send the compiler off in search of a package not yet in the semantic
+closure. (I am not dead set against it either.) All it needs to do
+is to check whether the pkg named in the stub is in the semantic
+closure and has a matching type decl.
+
+....
+> Perhaps we should disallow any usage that
+> would trigger such a "search" in the compilation unit where
+> the type stub itself is defined.
+
+For the interesting cases, such usage would effectively be illegal, because
+the completing decl is not in the semantic closure. For the non-interesting
+case, where it is in the closure...well, it is worth to introduce a special
+rule ? Nothing bad is going to happen.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 7, 2002,  2:24 PM
+
+> ...
+> > It would be like the current rules for attributes like 'Address,
+> > where you end up with an implicit dependence on package System
+> > if you use 'Address.  Of course in 99 44/100 % of the time,
+> > you would already have such a dependence.
+>
+> I actually believe it's 100% in the sense that my rules require
+> the existing dependence (or else the type remains incomplete).
+> I am not advocating an implicit dependence to be created, i.e.,
+> send the compiler off in search of a package not yet in the semantic
+> closure. (I am not dead set against it either.) All it needs to do
+> is to check whether the pkg named in the stub is in the semantic
+> closure and has a matching type decl.
+>
+> ....
+
+Now I don't like it again.  We worked to remove any search
+of the semantic closure from Ada 95.  One reason is the
+ripple effects, where the adding or removing of a "distant with"
+might change the legality of a compilation unit.  For example
+
+    package P_with_stub is
+        type T is tagged separate in P_with_completion;
+        procedure print(X : T);
+        type T_Ptr is access T;
+    end;
+
+    with P_with_stub, Q;
+    procedure test(Y : P_with_stub.T_Ptr) is
+    begin
+        P_with_stub.print(Y.all);
+                -- the legality of this depends on
+                -- whether Q has a "with" for P_with_completion
+                -- That seems undesirable.
+                -- Either it should be always illegal (my original rule),
+                -- or always legal (what I *thought* was your rule),
+                -- independent of "with"s on the otherwise unrelated package Q.
+    end;
+
+> > Perhaps we should disallow any usage that
+> > would trigger such a "search" in the compilation unit where
+> > the type stub itself is defined.
+>
+> For the interesting cases, such usage would effectively be illegal, because
+> the completing decl is not in the semantic closure. For the non-interesting
+> case, where it is in the closure...well, it is worth to introduce a special
+> rule ? Nothing bad is going to happen.
+
+I don't like the semantic closure rule, as explained above.
+I think we should say that a type defined by a type stub is
+incomplete throughout the compilation unit in which it is defined.
+In other compilation units (so long as they are *not* within the semantic
+closure of the completing package, to avoid circularities), it is
+equivalent to the completing_type wherever used in a context that
+requires a non-incomplete type.  Alternatively, go back to something
+based on explicit "with" clauses.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 7, 2002,  3:20 PM
+
+Tuck said:
+
+> It would be like the current rules for attributes like 'Address,
+> where you end up with an implicit dependence on package System
+> if you use 'Address.  Of course in 99 44/100 % of the time,
+> you would already have such a dependence.
+
+I don't like this idea at all from an implementation perspective (at least in
+Janus/Ada). The 'Address rule is silly, but harmless, as System is a predefined
+unit that is included in every compilation whether or not it is in the closure.
+(We have special code to reject uses of System when it is not withed).
+
+OTOH, this rule would require mucking around in the program library for some
+unit not processed with the other context clauses, and then effectively trying
+to with it. But the routines that handle withs expect to do all of them at once
+(and thus be able to order them appropriately), and expect to work into a
+freshly initialized symbol table. Changing either one of those properties would
+be none trivial.
+
+From an implementation perspective, either a rule based on semantic closure or
+on explicit withs would work. From a user perspective, it probably makes the
+most sense to require explicit withs.
+
+In any case, Erhard's point seems to be that he doesn't find the ripple effect
+particularly bad in this case. It can't change the meaning of a program, only
+change its legality. At worst, the user goes DUH! and puts in the with that
+they need (and perhaps are puzzled why they didn't need it before). So I think
+he is looking for a more compelling example of a problem with ripples in this
+case.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 7, 2002,  4:38 PM
+
+Unfortunately, it looks like we are entering into
+an area where implementations differ significantly.
+I vaguely remember Rational objecting to the "search
+the semantic closure" approach, because of incremental
+compilation.  For us, searching the semantic closure
+is somewhat harder than just going after the package
+when it is needed, but we can probably add a hash table
+that will solve the problem.
+
+I still don't like the "ripple" effect, so I guess I would
+vote for a "with" clause-based rule, which I think is
+straightforward for all implementations to support,
+albeit somewhat more complicated to specify.
+
+I am surprised Erhard isn't disturbed by the ripple effect.
+It just seems weird to me that someone somewhere removes
+an apparently unused with clause, and then a group of
+seemingly unrelated compilation units suddenly fail at
+compile-time.  I know there are tools and compiler warnings
+that indicate a "with" clause is not being used.  These might
+no longer be accurate in these sorts of situations.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Thursday, February 7, 2002,  6:25 PM
+
+<<I still don't like the "ripple" effect, so I guess I would
+vote for a "with" clause-based rule, which I think is
+straightforward for all implementations to support,
+albeit somewhat more complicated to specify.>>
+
+I agree with Tuck on this
+
+*************************************************************
+
+From: Erhard Ploedereder
+Sent: Thursday, February 7, 2002,  5:45 PM
+
+>    package P_with_stub is
+>        type T is tagged separate in P_with_completion;
+>        procedure print(X : T);
+>        type T_Ptr is access T;
+>    end;
+
+>    with P_with_stub, Q;
+>    procedure test(Y : P_with_stub.T_Ptr) is
+>    begin
+>        P_with_stub.print(Y.all);
+>                -- the legality of this depends on
+>                -- whether Q has a "with" for P_with_completion
+>                -- That seems undesirable.
+>                -- Either it should be always illegal (my original rule),
+>                -- or always legal (what I *thought* was your rule),
+>                -- independent of "with"s on the otherwise unrelated package Q.
+>    end;
+
+I will readily agree that this "ripple effect" is a kink (although none that
+would allow for really bad consequences or could not be repaired
+locally). But the "visibility model" has a quite similar kink:
+
+    package P_with_stub is
+        type T is tagged separate in P_with_completion;
+        type T_Ptr is access T;
+    end;
+
+    package P_with_completion is
+        type T is tagged record....;
+        type T_Ptr is access T;
+    end;
+
+    with P_with_X;
+    package R is
+        Y: P_with_X.T_Ptr;
+    end R;
+
+    with R;
+    procedure test is
+    begin
+        ... R.Y.all ....
+
+Now, under the "visibility" model, it will depend on which of the 2 packages
+is used for "P-with-X" whether or not one needs to add a "with
+P_with_completion" to test. I find that rather counterintuitive from
+the usage point of view (Users basically assume that the two "T"s are one
+and the same, as they should be.) It's clearly in the category of ripple,
+too.
+
+The issues that I see with "implicit dependencies" being created
+on a unit that isn't in the semantic closure already, are:
+- This has elaboration consequences.
+- This is tough/impossible to figure out for tools that try to
+  find the semantic or the link closure without doing full-fledged
+  semantic analysis.
+- The user might not actually be aware that (s)he just pulled in a
+  huge extra module with its support and support's support....
+
+I find those more scary than the relatively harmless ripple effect in
+the semantic closure model (where I simply can add a with-clause locally,
+if the ripple hits me).
+
+Unfortunately, your example also destroyed my basic assumption that for
+most interesting cases the completion will be in the semantic closure
+anyway, because the context of the operation needed the "real" T anyway.
+Your "test" is a good counter-example.
+I have no feeling yet how prevalent such usage might be. I do have a
+sneaking suspicion, though, that it's mainly the "is tagged" permission
+that creates most of those opportunities.
+In the style of Ada, would it not be sufficient to be content with formals
+that are of the access flavor ?
+In OOP-reality, these mutually dependent types will surely use the access
+type as component type and hence offer interfaces that take access params
+rather than T params. That would match the Java and C++ reality much better
+anyway than T params, which par force get copied when being assigned to
+components of T type.
+Just a thought ....
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 7, 2002,  6:09 PM
+
+> Your "test" is a good counter-example. I have no feeling yet how prevalent
+> such usage might be. I do have a
+> sneaking suspicion, though, that it's mainly the "is tagged" permission
+> that creates most of those opportunities.
+> In the style of Ada, would it not be sufficient to be content with formals
+> that are of the access flavor ?
+
+No, absolutely not.
+
+> In OOP-reality, these mutually dependent types will surely use the access
+> type as component type and hence offer interfaces that take access params
+> rather than T params.
+
+No, absolutely not. I'll use an access parameter over my dead body. (I don't
+believe there is a single one in Claw.)
+
+That's because you never want to force memory allocation issues on users, which
+you do if they have to use explicit access types. And if you're not using
+explicit access types, why would you want to force the users into the noise of
+requiring 'Access on every actual parameter object? "in out" and "access" are
+semantically equivalent inside of the units in the absence of explicit access
+types, so you don't lose anything by sticking with "in out".
+
+If you force users into memory allocation decisions, then the Java people who
+claim that you have to have garbage collection are right. We avoid the issue in
+Claw by letting the normal scoping mechanisms do any garbage collection
+necessary.
+
+> That would match the Java and C++ reality much better
+> anyway than T params, which par force get copied when being assigned to
+> components of T type.
+> Just a thought ....
+
+I'm not against letting people program like they would Java if they want, but
+I'm very against requiring them to do so. Ada is supposed to be better, after
+all. :-)
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 7, 2002,  6:23 PM
+
+> No, absolutely not. I'll use an access parameter over my dead body. (I don't
+> believe there is a single one in Claw.)
+
+Before Robert complains again about my getting too emotional :-), I should
+point out that I meant in the public interfaces of Claw. We do use a few access
+parameters in the private implementation of Claw, and there are a lot of them
+in the C interface routines that underlie Claw. But I don't believe in forcing
+people to include noise in all of their calls, or (worse) convincing them that
+it would be easier to allocate everything off the heap.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Thursday, February 7, 2002,  7:04 PM
+
+Well I don't mind people having odd idiosyncratic ideas about language
+features they don't like and therefore forbid themselves to use, but in
+evaluating new proposals, such voluntary crippling is irrelevant. The fact
+that Randy will not use access parameters in no way affects their first
+class citizenship in the language.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 7, 2002,  7:17 PM
+
+Of course not. However, Erhard was proposing that you could use ONLY access
+parameters with tagged separate incomplete types, and I find that sort of
+restriction unacceptable.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Thursday, February 7, 2002,  7:20 PM
+
+Seems OK to me, and I don't understand your objection. You did not give any
+technical argument, just a declaration about dead bodies, which did not give
+much of a clue as to what your objection is.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 7, 2002,  7:44 PM
+
+To expand on my original message a bit, the point is that any access
+manipulations occur inside the abstractions, not in the public interface. In
+Erhard's example, I probably would use an access type to avoid the assignment
+-- but that would occur completely inside the abstraction, and would not be
+visible to the user.
+
+This happens in Claw; consider a tool "selected" into a canvas. The public
+interface for doing that is:
+
+    procedure Choose (Easel  : in out Basic_Canvas_Type;
+                      Brush  : in out Claw.Brushes.Brush_Type'Class);
+
+and the implementation is something like (ignoring the various OS calls
+involved):
+
+    Easel.Brush_Access := Brush'Unchecked_Access;
+
+Since these are all controlled objects, the Finalization routines do the
+cleanup.
+
+Now, Canvases and Brushes are mutually dependent types. We got around that by
+declaring the root versions of both in the ultimate parent Claw. But, if we had
+had this new feature, we could have avoided that by declarations something
+like:
+
+    package Claw.Canvases is
+      type Basic_Canvas_Type is ...; -- Controlled
+      type Brush_Type is tagged separate in Claw.Brushes; -- Using Erhard's syntax
+      procedure Choose (Easel  : in out Basic_Canvas_Type;
+                        Brush  : in out Claw.Brushes.Brush_Type'Class);
+    private
+      type Brush_Access_Type is access all Brush_Type;
+      type Basic_Canvas_Type is record
+          ...
+          Brush_Access : Brush_Access_Type;
+          -- Or even Brush_Access : access Brush_Type; -- if AI-230 is adopted.
+      end record;
+    end Claw.Canvases;
+
+Erhard would like to prevent the declaration of Choose here, requiring the use
+of an access parameter.
+
+But that would force all calls (assuming locally declared brush objects, which
+is the most typical use of this construct) to include the 'Access "noise". That
+is something that is a constant annoyance, much like operators being invisible.
+It happens every time you write some code, and has the same effect as
+fingernails on a blackboard. We can't do anything about the existing language
+cases, but I certainly object to adding more cases like that.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Thursday, February 7, 2002,  7:55 PM
+
+OK, Randy's argument makes sense, I agree that the declaration of
+Choose makes sense (I am a bit dubious on the entire feature mind you :-)
+
+*************************************************************
+
+From: David Emery
+Sent: Thursday, February 7, 2002,  6:31 PM
+
+I think Randy's right on avoiding public access types like the plague.
+It really can be a fatal disease; many of the problems with X Windows
+came from "delegating" memory management to the application programmer.
+
+*************************************************************
+
+From: Erhard Ploedereder
+Sent: Thursday, February 7, 2002,  7:50 PM
+
+Randy, Dave, Give me a break...
+we are doing this in the context of mutually dependent
+types in different packages, not in the setting of any arbitrary type
+structure, so general insights on OOP don't help.
+
+Now, please tell me how you make two types mutually dependent (and hence
+require the type stubs) without using access types to these
+types to hook them into the respective components of the other type(s) ?
+
+You can't do it in Ada and you can't do it any other language unless
+the language hides the pointer behind a reference semantics so that all
+types are the equivalent of access types (with the dreaded memory
+implications).
+
+You can, of course, argue that there need not be a component decl in
+order to need the other type for some argument list of a subprog.
+Further that this subprog must be a primitive of the local type. (In
+all other cases, a subprog in a child seems a better way, anyway,
+since it would not require mutual dependency.)
+
+I am trying to understand how frequent one would expect this to be.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 7, 2002,  7:58 PM
+
+> Now, please tell me how you make two types mutually dependent (and hence
+> require the type stubs) without using access types to these
+> types to hook them into the respective components of the
+> other type(s) ?
+
+That's not the point at all. The point is that I don't want to make the access
+semantics visible through the public interface. Whether there is some in the
+implementation of the type is irrelevant. See the example I just posted of how
+the exact problem comes up in Claw and how we handled it, and how we'd have
+handled it if we had this feature.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 7, 2002,  8:10 PM
+
+> ...
+> Unfortunately, your example also destroyed my basic assumption that for
+> most interesting cases the completion will be in the semantic closure
+> anyway, because the context of the operation needed the "real" T anyway.
+> Your "test" is a good counter-example.
+> I have no feeling yet how prevalent such usage might be. I do have a
+> sneaking suspicion, though, that it's mainly the "is tagged" permission
+> that creates most of those opportunities.
+> In the style of Ada, would it not be sufficient to be content with formals
+> that are of the access flavor ?
+
+I don't think that is necessary.  The reason we allowed incomplete
+tagged as parameters was because they were always passed by reference.
+That implies that dereference should be legal for an incomplete
+tagged type as well, but anything that implies copying, assignment,
+or referencing a component would clearly not be permitted.
+Hence you could write "Y.all" if Y is access-to-incomplete-tagged, but
+about all you could do with it would be to pass it as a (non-controlling)
+parameter.
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent