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 X-Google-Thread: a07f3367d7,158ce2376534c35d X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder.news-service.com!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!gegeweb.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Derived private interface Date: Wed, 3 Aug 2011 11:01:52 +0200 Organization: cbb software GmbH Message-ID: References: <27656578-65aa-48b9-9f89-4ebd4e0cb02a@glegroupsg2000goo.googlegroups.com> <4e141501$0$6629$9b4e6d93@newsspool2.arcor-online.net> <4b2728fc-6127-45d8-a314-9fc491701c26@g12g2000yqd.googlegroups.com> <82vcve4bqx.fsf@stephe-leake.org> <4e15b223$0$6541$9b4e6d93@newsspool4.arcor-online.net> <1rlxo1uthv5xt.1agapd9q0mek4$.dlg@40tude.net> <1nvqqny2226ro$.1ixvoiht8zu8l$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: CEDal7W0jBNc7m2R8Nw0WQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: g2news1.google.com comp.lang.ada:20454 Date: 2011-08-03T11:01:52+02:00 List-Id: On Tue, 2 Aug 2011 16:16:27 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:1nvqqny2226ro$.1ixvoiht8zu8l$.dlg@40tude.net... >> On Mon, 1 Aug 2011 16:56:17 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" wrote in message >>> news:1rlxo1uthv5xt.1agapd9q0mek4$.dlg@40tude.net... >>> ... >>>> BTW, Generic_Dispatching_Constructor of Ada 2005 did not change much to >>>> Ada >>>> 95 because of tags. You still need a registering layer to maintain >>>> external name to tag mapping. >>> >>> It did eliminate one thing, the need to have a scheme to create an object >>> of >>> each tagged type. That forced the use of either a case statement or an >>> access-to-subprogram, either of which is error-prone. >> >> I don't consider the case statement because it is just a wrong pattern. >> Regarding mappings type ID to either a constructing function or tag, they >> are equivalent. Both require the same amount of maintenance. > > There are more sources of error when using access-to-subprogram; it's easy > to forget to create a routine or use the wrong one. Yes there is some advantage that the function in dispatching constructor is primitive: function Create (...) return T; For access-to-subprogram it is class-wide: function Create (...) return T'Class; As for using a wrong subprogram you can also register a wrong tag. That is same. BTW, the patterns are: -- with generic dispatching constructor type T is tagged ...; function Create (...) return T; procedure Register (ID : ID_Type; Construct : Tag); --- Usage: package P is type S is new T with ...; overriding function Create (...) return S; end P; package body P is ... begin Register (S_ID, S'Tag); end P; vs. -- Ada 95 access-to-subprogram solution type T is tagged ...; type Factory is access function Create (...) return T'Class; procedure Register (ID : ID_Type; Constructor : Factory); -- Usage: package P is type S is new T with ...; end P; package body P is function Create (...) return T'Class is ... end Create; ... begin Register (S_ID, Create'Access); end P; >>> There is no possibility of eliminating the need for some sort of registry -- >>> although in some cases you can use the one built-into the language (the >>> External_Tag). There has to be a mapping somewhere of some sort of key to a >>> tag, since it isn't possible to export tags to the "real world". >> >> It is possible, and even required for distributed weakly coupled >> applications, but in order to do that you have to export the types >> themselves rather than their tags. > > It might be possible for some non-Ada language, but it's not possible for > Ada (and this is an Ada site and I was only talking about Ada here). Well, if Ada designers are serious about addressing distributed systems (Annex E), that has to happen. Either a kind of IDL must be put into the Ada standard (highly undesired) or some other, more reasonable, means must be provided to populate types. [Of course the type system must be brought in order before even considering this sort of issues.] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de