Re: Child Package Operator Visibility

["(see below)" <yaldnif.w@blueyonder.co.uk>]

On 07/04/2008 16:03, in article
6b08d1d0-1896-4951-8528-e11bef196dd7@1g2000prf.googlegroups.com, "Adam
Beneschan" <adam@irvine.com> wrote:

> On Apr 5, 7:19 am, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
>> On 05/04/2008 15:03, in article
>> L-udnRBPxNSpGWranZ2dnUVZ_gKdn...@comcast.com, "pakman"
>> 
>> <pakman...@nospam.com> wrote:
>>> Recently, in the process of illustrating Ada 95 child packages in a course I
>>> teach, I implemented the Fractions.Comparisons package from N. Cohen's Ada
>>> as a Second Language, 2nd ed text. In the test program, I withed the
>>> Fractions and Fractions.Comparisons packages, and then specified the use
>>> type Fractions.Fraction_Type for direct visibility of the Fractions package
>>> operators. I was surprised that the Fractions.Comparisons package operators
>>> were not directly visible (that is, I was not able to test for A < B). To
>>> make the example work, I added the use Fractions.Comparisons statement.
>> 
>>> So, my questions are: 1) Why didn't the use type work for the
>>> Fractions.Comparisons operators, and 2) how do I make the operators directly
>>> visible?
>> 
>> (1) Because the operations in Fractions.Comparisons are not primitive
>> operations of the fraction type.
>> 
>> (2) Redesign the package structure (abolish Fractions.Comparisons) so that
>> the comparisons are primitive.
> 
> Or just "use Fractions.Comparisons"?  I don't actually have this book,
> so I'm just making a guess as what might work.

That is what the OP seemed to want to avoid, but sure, it's not a big deal.
However, I see no plausible reason for the comparison operations being
segregated from their comparand type in a child package.

As it happens I have a rationals package of my own and it has two children,
but the parent contains all of the type-defining operations.
The children are (a) an I/O package and (b) a combinatorics package.
Neither should be forced on users of the rational arithmetic facilities.
 
> In fact, this sort of thing is an idiom I used to use a lot, before
> Ada 95 gave us "use type".  I would declare a package with the types I
> wanted to declare, and then define a nested package Operators which
> redefined all the operator symbols on those types using renaming, so
> that another package could say "use Pkg.Operators" without having to
> "use Pkg" which would make too much visible.

"use Pkg" really shouldn't do that if Pkg is well designed.
-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk