!ASIS Issue #102 !topic generic child units of generic parents, traversal questions !reference ASIS 95-13.36, 13.35, 13.33, 15.26, 15.27 !from Gary Barnes 98-12-17 !keywords generic child units parents traversal Enclosing_Element Is_Part_Of_Instance Is_Part_Of_Implicit Corresponding_Declaration Corresponding_Body !discussion An interesting question for Enclosing_Element... Imagine a generic parent unit and a generic child unit. generic generic type Tp is (<>) type Tc is (<>); package Parent is package Parent.Child is end Parent; end Parent.Child; And an instance of that parent plus a WITH of the instance and a WITH of the child. package Instance is with Instance; new Parent (Integer); with Parent.Child; package Usage is generic package Aha renames Instance.Child; --<<==here end Usage; Let's say that an ASIS application traverses the Usage unit down to the renames reference to the Child identifier. And then it uses Asis.Expressions.Name_Declaration to jump to the implicit declaration of the Child interface that lurks within the Instance instantiation. This implicit declaration of Child is one that exists (or perhaps, "can be named") only in a context where a) there is an instantiation of the parent generic unit visible and b) the child generic unit is also visible. It is an implicit declaration. So therefore I suppose there will be ASIS implementations that don't implement it (or won't allow access to it, or whatever). They can stop reading at this point. For the ASIS implementations that do have it or that implement it... When the ASIS appliciation takes the A_Generic_Declaration element corresponding to that implicit Child generic declaration and passes it to Enclosing_Element, what is the result? There is no literal piece of text that caused the implicit Child to spring into existence so there is no obviousls correct answer. I can imagine at least three possibilities, 1) The result is the declaration for Usage. It is the context that allowed the implicit declaration to exist (or to be nameable). 2) The result is the declaration for Instance. It is the instantiation from which the implicit declaration can be named. It is also the instantiation of the parent that would determine those things that a Child instantation would inherit from its Parent instantiation. 3) The result is the declaration of Parent.Child itself. (1) would be workable. It would not always return A_Declaration---imagine the parent being instantiated in a declare/begin/end. The context would be the block and not some specific A_Declaration element. (2) could be useful. In order to predict the full properties of a Child instance it is necessary to know the associated Parent instance and this might be the only method of determining that instance short of an exhaustive search of the context. (Imagine an application that arrived at the implicit Child by calling Corresponding_Generic_Element for an element from an instantiation of Child. The application would not know ahead of time that it was working with a generic child of a generic parent.) (3) would be workable, but the application might be able to get the same information by invoking Corresponding_Generic_Element or something on the name of the Child (see the next topic). I tend to think that (2) would be the most useful to applications. This is the one level child case. There are also two level, three level, four level, ... cases to consider. (2) seems overall to be the most interesting. But, are there other candidates? ============================================================================== And here is a related interesting question for Corresponding_Generic_Element and for Is_Part_Of_Instance... The implicit Child declaration, is it Is_Part_Of_Instance? It is not a literal textual component of the Parent unit. However, it exists and is nameable only due to the existance of the Instance and it is named as if it were a subcomponent of the instance. So is it part of an instance for the purposes of Is_Part_Of_Instance? The obvious answer would seem to be No, but that might not be the best answer, see below. How does an ASIS application traverse from an implicit Child declaration to the actual Child generic declaration? This is an example of a multi-part declaration that I don't believe is presently covered by ASIS. There can be any number of implicit Child declarations in the library. We need to jump from one implicitly declared generic spec to the corresponding identical explicitly declared generic spec. One possibility that comes to mind is the Corresponding_Generic_Element interface. The implicit Child declaration acts as if it is part of the Instance instantiation. It exists because the Instance exists and it inherits generic formal values from the Instance just as if it were actually part of the Instance. If Corresponding_Generic_Element is invoked on a name from within the implicit Child declaration (either the name of the Child itself or the name of some subcomponent), what is the result? If the result is the corresponding element from the original Child generic declaration then the traversal problem is solved. But that then also needs to reflect back to the answer for the Is_Part_Of_Instance question for the implicit Child. It would then be appropriate to answer Is_Part_Of_Instance as Yes. Or, answer Is_Part_Of_Instance No and add implicit generic Child declarations to the list of things taken care of by a call to Corresponding_Declaration. Call it with the implicit generic declaration and it can return the explicit generic. Although, given that it is more customary for that interface to jump from explicit instance to implicit declaration, having it jump from implicit declaration to explicit declaration might seem odd. !resolution Reject. Incorporated via editorial changes. Please see Comment c126.