* Instantiation of child generics? @ 1996-07-26 0:00 Dale Stanbrough 1996-07-26 0:00 ` Tucker Taft 1996-07-26 0:00 ` Robert A Duff 0 siblings, 2 replies; 7+ messages in thread From: Dale Stanbrough @ 1996-07-26 0:00 UTC (permalink / raw) Hi, I'ld like to create an abstract generic queue package with bounded and unbounded children. However I have been thwarted in all attempts to instantiate them. Also I don't really understand the rules for instantiaion of child generics. Can anyone explain them? e.g. generic type element is private; package queues is type queue is abstract tagged null record; procedure init return queue is abstract; procedure enqueue(item:in out queue; item:element) is abstract; -- etc end queues; generic size :natural; package queues.bounded is type queue is new queues.queue with private; procedure init return queue is abstract; procedure enqueue(item:in out queue; item:element) is abstract; private type queue is new queues.queue with null record; -- for now... end; How do I instantiate this? with queues.bounded; package myQ is new queues.bounded(integer, 5); results in Gnat telling me "invalid prefix in selected component "queues"" Also will my (re)use of the identifier "queue" in the packages cause any problems for me? It seems to compile ok, but i'm concerned that there might be some nasty visibility issue lurking around the corner... Thanks, Dale ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Instantiation of child generics? 1996-07-26 0:00 Instantiation of child generics? Dale Stanbrough @ 1996-07-26 0:00 ` Tucker Taft 1996-07-26 0:00 ` Kevin J. Weise 1996-07-26 0:00 ` Robert A Duff 1 sibling, 1 reply; 7+ messages in thread From: Tucker Taft @ 1996-07-26 0:00 UTC (permalink / raw) Dale Stanbrough (dale@goanna.cs.rmit.edu.au) wrote: : ... Also I don't really understand the rules for : instantiaion of child generics. Can anyone explain them? You should think of a child of a generic as a nested generic, which is only visible to those who choose to mention it in a with clause. Since it is conceptually a nested generic, you can only instantiate it once you have already instantiated the enclosing generic. Given your example below, you would first instantiate "queues": with queues; package queue_inst is new queues(Integer); Then you would instantiate the "nested" generic "bounded" as follows: with queue_inst; -- The instance of the enclosing generic with queues.bounded; -- Makes the nested generic visible in all instances package bounded_inst is new queue_inst.bounded(200); If "bounded" had been truly nested, rather than a child, the only difference would be that you would omit the "with queues.bounded;" The effect of "with queues.bounded;" is to "plug" the child "bounded" into its parent generic "queues", meaning that "bounded" becomes visible in all instances of "queues." We struggled during the 9X process with children of generics, since it is certainly a bit counterintuitive that you "with" "queues.bounded" whereas you instantiate "queue_inst.bounded." However, if you think of a "with" clause as having the effect of "plugging" a child into its parent unit, then you should be able to understand why children of generics work the way they do. : e.g. : generic : type element is private; : package queues is : type queue is abstract tagged null record; : : procedure init return queue is abstract; : : procedure enqueue(item:in out queue; item:element) is abstract; : -- etc : end queues; : : : generic : size :natural; : package queues.bounded is : : type queue is new queues.queue with private; : : procedure init return queue is abstract; : : procedure enqueue(item:in out queue; item:element) is abstract; : private : type queue is new queues.queue with null record; -- for now... : end; : How do I instantiate this? : with queues.bounded; : package myQ is new queues.bounded(integer, 5); : : results in Gnat telling me "invalid prefix in selected component "queues"" GNAT is correct; the prefix to "bounded" should be an instantiation of queues, not queues itself. : Also will my (re)use of the identifier "queue" in the packages cause any : problems for me? It seems to compile ok, but i'm concerned that there might : be some nasty visibility issue lurking around the corner... Only if you "with" and "use" both packages. Even then, you can still use a full expanded name where there is a name conflict. : Thanks, : Dale -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Instantiation of child generics? 1996-07-26 0:00 ` Tucker Taft @ 1996-07-26 0:00 ` Kevin J. Weise 1996-07-27 0:00 ` Robert A Duff 0 siblings, 1 reply; 7+ messages in thread From: Kevin J. Weise @ 1996-07-26 0:00 UTC (permalink / raw) stt@henning.camb.inmet.com (Tucker Taft) wrote: >Dale Stanbrough (dale@goanna.cs.rmit.edu.au) wrote: >: ... Also I don't really understand the rules for >: instantiaion of child generics. Can anyone explain them? > >You should think of a child of a generic as a nested generic, >which is only visible to those who choose to mention it in a with clause. >Since it is conceptually a nested generic, you can only instantiate >it once you have already instantiated the enclosing generic. ... > >We struggled during the 9X process with children of generics, since >it is certainly a bit counterintuitive that you "with" "queues.bounded" >whereas you instantiate "queue_inst.bounded." However, if you think >of a "with" clause as having the effect of "plugging" a child into >its parent unit, then you should be able to understand why children of >generics work the way they do. > FWIW, Mr. Taft, I don't think it is counterintuitive at all. If the effect is the same as if the child generic unit were nested within the parent generic unit, you would still follow the same process: instantiate the parent first, then instantiate the child WRT the instance of the parent. I think the Ada9X team did a great job on child units. Now, if you want counterintuitive, I think there are some other areas that may qualify. But they've probably already been hashed over & certainly belong in a different thread. -------------------------------------------------------------------------- Kevin J. Weise email: kweise@sed.redstone.army.mil COLSA Corp. voice: (205) 842-9083 Huntsville, AL .. standard disclaimers apply ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Instantiation of child generics? 1996-07-26 0:00 ` Kevin J. Weise @ 1996-07-27 0:00 ` Robert A Duff 1996-07-30 0:00 ` Dale Stanbrough 0 siblings, 1 reply; 7+ messages in thread From: Robert A Duff @ 1996-07-27 0:00 UTC (permalink / raw) In article <4taqvl$i11@michp1.redstone.army.mil>, Kevin J. Weise <kweise@c3i-ccmail.sed.redstone.army.mil> wrote: >FWIW, Mr. Taft, I don't think it is counterintuitive at all. If the effect >is the same as if the child generic unit were nested within the parent >generic unit, you would still follow the same process: instantiate the >parent first, then instantiate the child WRT the instance of the parent. Yes, that all makes sense. What is counter-intuitive is that you have to say "with Parent_Generic.Child_Generic;". Normally, you can't reach into a generic and reference something inside it (you could never refer to Generic_Package.Nested_Thing from outside). This requires a special visibility rule (see the last sentence of 10.1.6(2)). And that "with" magically makes Parent_Instance.Child_Generic visible. I think that's what Tucker meant by "counter-intuitive". Once you've swallowed that little oddity, everything makes sense -- instantiate the outer thing, and then instantiate the Instance.inner-thing. >I think the Ada9X team did a great job on child units. The credit goes to Tucker and to Norman Cohen, who both apparently came up with the same idea, somewhat independently. (Tucker thought of it all one night (he explained to me the next morning), and then realized it was essentially the same as what Norman Cohen had proposed some months earlier.) The previous language definition was pretty hopeless, actually. Credit should also goes to the Swiss delegation to WG9, who pushed the MRT into thinking about generic children in the first place. >Now, if you want counterintuitive, I think there are some other areas that >may qualify. But they've probably already been hashed over & certainly >belong in a different thread. OK, I'm listening for different threads, with my language-designer hat on. ;-) - Bob ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Instantiation of child generics? 1996-07-27 0:00 ` Robert A Duff @ 1996-07-30 0:00 ` Dale Stanbrough 1996-07-30 0:00 ` Robert A Duff 0 siblings, 1 reply; 7+ messages in thread From: Dale Stanbrough @ 1996-07-30 0:00 UTC (permalink / raw) Robert A Duff writes: ">Also will my (re)use of the identifier "queue" in the packages cause any >problems for me? Should be OK, but I don't particularly like that style." ...where the style is defining a type name in an "abstract" package, and reusing the same name in concrete implementations in child packages. (e.g. abstract type "queue", concrete bounded type "queue" and concrete unbounded type "queue"). The benefits are that (if you use use) you can write your code myQ:queue; and get diff. implementations by changing the with clause. What problems do you forsee in doing this? Dale ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Instantiation of child generics? 1996-07-30 0:00 ` Dale Stanbrough @ 1996-07-30 0:00 ` Robert A Duff 0 siblings, 0 replies; 7+ messages in thread From: Robert A Duff @ 1996-07-30 0:00 UTC (permalink / raw) In article <4tkuv1$3jm@goanna.cs.rmit.edu.au>, Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU> wrote: >concrete unbounded type "queue"). The benefits are that (if you use use) >you can write your code > > myQ:queue; > >and get diff. implementations by changing the with clause. What problems >do you forsee in doing this? Well, it's hardly a big deal, but I just don't like having zillions of things called "queue". It seems confusing. Your "benefit" above only works if there is only one type of queue being used in this module, by the way. If I were using the style of calling all queue types "queue", I would prefer to refer to Whatever_Pkg.Queue. I really don't mind doing a search-and-replace operation if I want to change what sort of queue it is. Emacs can search through multiple files, so it's not that hard. And if you make a mistake, it will likely be detected at compile time. You need to do that search anyway, just in case somebody used an expanded name instead of a use_clause. Finally, if you really want flexibility, you can use abstract class-wide objects (or pointers to them), and try to localize the creation of objects in a Factory package (which is often a good idea anyway). Again, it's no big deal, either way. - Bob ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Instantiation of child generics? 1996-07-26 0:00 Instantiation of child generics? Dale Stanbrough 1996-07-26 0:00 ` Tucker Taft @ 1996-07-26 0:00 ` Robert A Duff 1 sibling, 0 replies; 7+ messages in thread From: Robert A Duff @ 1996-07-26 0:00 UTC (permalink / raw) In article <4t9itp$imd@goanna.cs.rmit.edu.au>, Dale Stanbrough <dale@goanna.cs.rmit.edu.au> wrote: >Hi, > >I'ld like to create an abstract generic queue package with bounded >and unbounded children. However I have been thwarted in all attempts >to instantiate them. Also I don't really understand the rules for >instantiaion of child generics. Can anyone explain them? > > >e.g. > > generic > type element is private; > package queues is > type queue is abstract tagged null record; > > procedure init return queue is abstract; > > procedure enqueue(item:in out queue; item:element) is abstract; > > -- etc > end queues; > > > generic > size :natural; > package queues.bounded is > > type queue is new queues.queue with private; > > procedure init return queue is abstract; > > procedure enqueue(item:in out queue; item:element) is abstract; > > private > type queue is new queues.queue with null record; -- for now... > end; > > >How do I instantiate this? > > with queues.bounded; > package myQ is new queues.bounded(integer, 5); You need to instantiate the parent first: with queues; package integer_queues is new queus(element => integer); Now, conceptually, for every child of queues, there is a generic child of integer_queues. But these are not visible unless you "with" the corresponding child of queues. Also, they are somewhat mythical -- the compiler will normally not create them unless needed (now can it? -- it can't know about all those children at compile time). with integer_queues; with queues.bounded; -- Makes Integer_Queues.Bounded visible. package bounded_integer_queues is new integer_queues.bounded(size => 5); Or, you could make the instance a child: with integer_queues; with queues.bounded; package integer_queues.bounded_integer_queues is new integer_queues.bounded(size => 5); -- You can't call this instance integer_queues.bounded, because -- that's the name of a generic. Or, you could nest them inside another package: with queues; -- Not strictly necessary, but I like to write this. with queues.bounded; package My_Queues is package int_queues is new queus(element => integer); -- Here, int_queues.bounded is visible, because queues.bounded -- is "with"ed, so we can instantiate it: package bounded is new int_queues.bounded(size => 5); ... end My_Queues; >results in Gnat telling me "invalid prefix in selected component "queues"" > >Also will my (re)use of the identifier "queue" in the packages cause any >problems for me? Should be OK, but I don't particularly like that style. - Bob ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~1996-07-30 0:00 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-07-26 0:00 Instantiation of child generics? Dale Stanbrough 1996-07-26 0:00 ` Tucker Taft 1996-07-26 0:00 ` Kevin J. Weise 1996-07-27 0:00 ` Robert A Duff 1996-07-30 0:00 ` Dale Stanbrough 1996-07-30 0:00 ` Robert A Duff 1996-07-26 0:00 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox