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: 103376,12a63150f4f961a X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,BIG5 Received: by 10.68.136.33 with SMTP id px1mr4307714pbb.7.1336168851650; Fri, 04 May 2012 15:00:51 -0700 (PDT) Path: pr3ni4479pbb.0!nntp.google.com!news1.google.com!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: OOP in Ada: Alternatives for "protected" scope Date: Sat, 5 May 2012 00:00:41 +0200 Organization: cbb software GmbH Message-ID: <17kcn9g4qeg7j.5xole2f4bwbj$.dlg@40tude.net> References: <1vn9nv4aqm9a3.1tqzc91idjlbs$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: KA5xyyPKkGZLxk9XJsNqLQ.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 8bit Date: 2012-05-05T00:00:41+02:00 List-Id: On Fri, 4 May 2012 20:48:53 +0200, Felix Krause wrote: > On 2012-05-03 21:56:51 +0000, Dmitry A. Kazakov said: >> >> If Do_Something varies in children they should override it. The reusable >> parts common for all children can be factored out as a private class-wide >> operation. > > Compared to my version (with redispatching issues fixed), this > alternative enforces a weaker contract. I don't like re-dispatch, it is a design bug to me. >> This is exactly what Ada's private is. The correspondence goes as follows: >> >> "Public" <-> Ada' public operation >> "Protected" <-> Ada's private operation >> "Private" <-> An operation defined in the package body > > So, to be able to use these visibility scopes, the class hierarchy must > follow the layout of the package hierarchy. That depends on what you mean. Classes (types constituting them) stretch across packages, as types don't live in the vacuum. Ada separates types and visibility. Comparing to other languages it is a great advantage. I understand that you see it differently, but that is because you haven't yet accustomed to the Ada's model. Note that Ada has another (inferior) model as well. It can be seen in Ada protected and task types. They are mess. It was a mistake. > I think this is a > disadvantage for some reasons: > > * Given the scenario that you use an Ada software library containing > tagged types, you have to subclass these types in child-packages within > the package layout of the library. Only if you want to access private, i.e. implementation-dependent, stuff. Note that when a package depends on the implementation details of another package, this constitutes a tight coupling. Ada requires the programmer to manifest this design decision in the form of a parent-child package relation. This IMO is a good thing. You cannot access the implementation details if you don't state your intention making it visible for the reader. Note also that this decision is all on the child's side. In the competing model, any derived type always get access, so the decision is on the parent type side. This is a bad design because it forces the programmer to make his choice early and, maybe, it does a wrong person. > I for myself would rather want to > place my code in the package hierarchy of my application. That is not a problem, you can rename packages. > * It doesn't work with generics: > > generic > -- ... > package P is > type A is tagged private; > -- �K > end P; > > package Q is > package P_Instance is new P (...); > > type B is new P_Instance.A with private; > end P.Q.R; You use a generic child: generic package P.Q is type B is new A with private; private ... -- You have visibility of P's private here end P.Q; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de