From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8385fc6e4bf20336,start X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!i7g2000prf.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Generics with concrete and class-wide types Date: Mon, 31 Mar 2008 13:22:10 -0700 (PDT) Organization: http://groups.google.com Message-ID: <279b6f4f-36cf-446f-8b54-fd72b957b22f@i7g2000prf.googlegroups.com> NNTP-Posting-Host: 85.0.247.156 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1206994930 32305 127.0.0.1 (31 Mar 2008 20:22:10 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 31 Mar 2008 20:22:10 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i7g2000prf.googlegroups.com; posting-host=85.0.247.156; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20686 Date: 2008-03-31T13:22:10-07:00 List-Id: Consider a generic subprogram that makes sense for arguments of both class-wide type and a concrete type. As a motivating example, there might be a hierarchy of iterator types rooted in some imaginary Iterator type that is itself defined in the generic package with the element type as its own formal parameter. There are concrete iterator types that are derived from this root Iterator type (exactly: from some instantiation thereof). There might be also a generic subprogram that operates on the iterator given as its parameter. This subprogram takes two formal generic parameters: the element type and the iterator type. Now - on one hand it makes sense to have a hierarchy of iterators and benefit from loose coupling and other features of OO, but on the other hand the iterators themselves can be lightweight objects that are used in tight loops and we can expect them to be fast, therefore we could benefit from *avoiding* the dynamic dispatch if there is enough context to do so. Both make sense, depending on the context at the call site. To achieve both benefits the user might instantiate the subprogram for the Iterator'Class type (to be exact: for the 'Class of some instantiation of Iterator) in the context where only a class-wide type is available, like within some other polymorphic subprogram; and for the concrete type, like My_Concrete_Iterator, in the context where the concrete type is available, with the hope that such an instantiation can be more easily inlined. The sketch of types involved is: generic type T is private; -- element type package Iterators is type Iterator is interface; function Get (I : Iterator) return T is abstract; -- and so on for other operations... end Iterators; and at the user side (let's suppose the user works with Integers only): package body My_Stuff is package Iterators_Integer is new Iterators (T => Integer); type My_Concrete_Iterator is new Iterators_Integer.Iterator with ... overriding function Get (I : My_Concrete_Iterator) return Integer; -- and so on for other operations... end My_Stuff; Now, the generic subprogram that operates on the given iterator, *without* using dynamic dispatch, can have the following form: generic type Element is private; type Iterator_Type (<>) is private; with function Get (I : Iterator_Type) return Element is <>; -- and so on for all other operations that are needed by this subprogram procedure Some_Procedure (I : in Iterator_Type); This works fine for direct instantiation with My_Concrete_Iterator: procedure SP is new Some_Procedure (T => Integer, Iterator_Type => My_Concrete_Iterator); The problem is that I failed to instantiate Some_Procedure for Iterator_Integer.Iterator'Class, which I could then reuse for My_Concrete_Iterator as well as for My_Other_Concrete_Iterator and so on: -- does not compile: procedure SP is new Some_Procedure (T => Integer, Iterator_Type => Iterator_Integer'Class); -- Bang! Bang, because relevant iterator operations cannot be found - the ones that are found have *wrong signatures*. Separate version of Some_Procedure can be written for polymorphic operations: generic type Element is private; with package Its is new Iterators (T => Element); -- no need to enumerate any operations, the interface serves its purpose procedure Some_Procedure (I : in Its.Iterator'Class); This works fine when some instantiation of base Iterator type is given: procedure SP is new Some_Procedure (T => Integer, Its => Iterators_Integer); and then SP can be used with My_Concrete_Iterator, presumably dispatching on all calls to iterator in its body. My expectation is that there should be a way to implement only one generic procedure that can be instantiated for both concrete types and for 'Class type. Otherwise, I would need to provide both versions of Some_Procedure, which not only looks like unnecessary duplication of code (the implementations would be even textually identical!), but also seems to be impossible - for some reason these two versions cannot exist in the same package. What the heck? I did not expect two orthogonal language features (generics and OO) to interact in such a way. Is there a good solution to this problem? -- Maciej Sobczak * www.msobczak.com * www.inspirel.com