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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: grassroots thoughts on access types Date: Fri, 9 Feb 2018 18:19:27 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <5d9134c9-a7d4-468e-8685-ebbb393eabea@googlegroups.com> NNTP-Posting-Host: 9s2HXjYgtb87Rt4JbNw44Q.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:50341 Date: 2018-02-09T18:19:27+01:00 List-Id: On 2018-02-09 18:01, Jeffrey R. Carter wrote: > Others have responded to your questions. I'd like to mention my thoughts > on using access-to-object types (which I'll call "access types") in > general. (By "use", I'm referring to designing code with access types, > not to using them when required to in order to reuse existing code. > Gnoga, for example, requires you to supply some access values to use it.) > > It's very rare to actually need to use access types in Ada. Other than > while learning the language, it's quite likely that you'll never > encounter a situation in which you'll need them. So while it's important > to learn how they work, you shouldn't be designing in terms of them. > > My personal rules for designing with access types: > > 1. Don't use access types > 2. If you think you need access types, see rule 1. > 3. If you still think you need access types, don't use visible or > anonymous access types > 4. If you think you need visible or anonymous access types, see rule 3. > 5. If you still think you need visible or anonymous access types, then > you shouldn't design software. I mostly agree with that, yet there are some notable exceptions from these rules. a. Dispatching operation. It cannot have a named access type. The conflicting design rule here is that *all* operations must be dispatching and any type must have a class. b. Anonymous access type accepts arguments without explicit type conversion. Type conversions are always bad, ones exposing run-time hazard are more than bad. c. Mix-in discriminant, anonymous access type is the only way in many cases. Mix-in itself is a horrid design pattern, but there is no multiple inheritance here to replace mix-in and no proper classes of protected and task types either. In general, anonymous access type is the only way to enforce referential semantics. It would be great if Ada had it decoupled that from pointers. Unfortunately it did not. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de