Re: Limited_Controlled, orthogonality and related issues

["Adam Beneschan" <adam@irvine.com>]

Randy Brukardt wrote:
> "Maciej Sobczak" <no.spam@no.spam.com> wrote in message
> news:eoned5$663$1@cernne03.cern.ch...
> ...
> > In conclusion, my decision to make T and S controlled appeared to not be
> > orthogonal to the rest of the package.
> >
> > What are your thoughts about this?
>
> It's dubious to have two abstractions in the same package. It's a nice
> simplification compared to other languages, but it's usually better to have
> fewer types in one package rather than more. If T and S were in different
> packages, this problem wouldn't happen. Note that one of the packages could
> be nested or a child, and that would still have the visibility on the
> private part.
>
> Something like:
>
> package Root is
>    type S is limited private;
> ...
> end Root;
>
> package Root.Child is
>    type T is limited private;
>    procedure Do_Something (A : T, B : S);
> ...
> end Root.Child;

Yep, I hadn't thought of that.  And if you use nested inside of child
packages, you could do something like this:

package Root is
    type S is limited private;
    package Inner is
         type T is limited private;
    end Inner;
    subtype T is Inner.T;
    procedure Do_Something (A : T; B : S);
    ...

Now Do_Something isn't a primitive operator on T so there's no 3.9.2
error.  Whether this is "appropriate" or not, I can't tell without
knowing more about the exact types and operations involved.  For the
examples I can think of that I've worked with, S might be some sort of
container type, T might be an iterator to help search through selected
objects in S, and Do_Something might be a routine that returns
successive elements of S that meet some criteria.  In a case like that,
Do_Something probably "belongs" inside the Inner package.  But there
are probably other cases where you would prefer to have Do_Something
outside the Inner package.  It's hard to say without knowing any
details.  But the point is, you can use a construct like this to avoid
the "multiple dispatch" error, and this solution will still let you
implement S and T any way you want in the private part---as opposed to
making S and T part of the same package which prevents you from
implementing both of them as tagged types.

                              -- Adam