Re: grassroots thoughts on access types

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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