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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: A bad counterintuitive behaviour of Ada about OO Date: Mon, 11 Aug 2014 10:23:09 +0200 Organization: cbb software GmbH Message-ID: References: <932kntuq5rrr.8sumwibqrufn.dlg@40tude.net> <1ohy7vnbntskq$.h139ov04mlxu$.dlg@40tude.net> <536e35d6-f1de-4917-9300-26d78686eaf2@googlegroups.com> <1w3wuhu3d4nxi$.qluzbi0gtlxx$.dlg@40tude.net> <2extr7bydwfw.tcda12f9xnq9.dlg@40tude.net> <4a3996f3-666e-404a-ad8b-ff1832751787@googlegroups.com> <19297tmx9dt9q.1p2p4i0odtkyw.dlg@40tude.net> <2e3dyovp6wty.myprjpgzi2uy$.dlg@40tude.net> <6c67704a-d399-433d-bd8e-4566e79defaf@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: yj8+JIQUMOEawvIM7K49kA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:21658 Date: 2014-08-11T10:23:09+02:00 List-Id: On Mon, 11 Aug 2014 00:58:12 -0700 (PDT), Maciej Sobczak wrote: > W dniu poniedziałek, 11 sierpnia 2014 09:41:09 UTC+2 użytkownik Dmitry A. Kazakov napisał: > > In other words, this has to work as well: > > procedure Use_Specific_Factory (F : in Specific_Factory) is > > SP : Specific_Product := F.Make_Product; And it worked in the example I provided. > And there is no way to make *both* work in Ada. You can get one or the > other but not both. Of course there is a way. If you have two operations with different profiles you can overload them. >> Where is a problem? Do this (in another package): >> >> not overriding >> function Make (F : not null access B_Factory) return B; >> >> Observe: not overriding. > > And this is where your idea breaks down. The Make operation *must* be > overriding, otherwise I will not be able to use Factory'Class. You don't need Factory'Class since the return type is fixed to B. If it were B'Class you could have a hierarchy of B-and-its-descendant-factories. But that won't be a hierarchy of A-factories or A-and-its-descendant-factories. You need something to vary to have a hierarchy. Which is why it is called covariance or contravariance. Varying could be Factory or Product or both (MD). No hierarchy, no variance. >>> Useless? >> >> Yes, useless. If you know all types involved you call a specific subprogram >> or simply declare the object. Work done. > > I might not know the specific factory type. No, you know it, because the only factory that returns B is the B-factory and nowhere in your examples you have one with a class-wide factory and a specific product type. If you wrote one, you would see what is wrong with your idea: procedure Foo (F : A_Factory'Class) is X : B := Make (F); This does not work because it could be *any* factory, e.g. an A-factory. You *must* specify the factory type: procedure Foo (F : A_Factory'Class) is X : B := B (Make (B_Factory (F))); MD would do this automatically. But, again, the whole exercise is useless. If you know it must be B, there is no need in any factories: X : B; >> Factories are used *only* when types are unknown in advance. > > Not only. I might want to use specific factory from the hierarchy of > factories, too. The type of the product is unknown when a factory is used, that is all and single idea of having a factory. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de