Re: Elimination of "use" clauses

[Richard D Riehle <LaoXhai@ix.netcom.com>]

In article <3798E50D.100976B@averstar.com>,
	Tucker Taft <stt@averstar.com> wrote:

>Richard D Riehle wrote:

 -- Richard's code appended to end of this article to avoid length example

>The major difference is that the operators are no longer inherited
>as part of a derived type definition.

 I understand that the inheritance disappears.  For the kind of situations
 involved, that may not be a real problem.  

>In general, the "ops" package idiom was an Ada 83 work-around.
>Now that we have use-type, I recommend against proliferating it further.

 Yes, the "ops" package was a work-around.  A very good one, it turns out.
 Even with its drawbacks, and there are some, the question is whether it is
 better to export all the operators on a type or only some.  The idea of
 making a type "private" and declaring the operators was suggested and that
 is also a good solution.  However, for an enumerated type, this is not a
 good solution.  Sometimes I only want an equality operator available on an
 enumerated type Should I require the client to rename it or should I export it
 in some explicit way.  I would prefer an explicit export that targets only
 the operators I want the client to have.  The "use type", while often useful,
 may export more than I want.   

>There are ways to work with a language, and ways to fight against it.
>In Ada 95, the "use type" is definitely the language-defined way to
>deal with operator visibility.  In Ada 83, there really wasn't
>any particularly good language support for operator visibility,
>so various approaches were adopted.

 I don't consider the "ops" package as a way to "fight" against the language.
 It is simply an alternative that sometimes makes sense.  The naked use clause,
 the "use type", the renaming of operators, are all other alternatives that
 sometimes make sense.  A designer must decide which option is most appropriate
 for the solution.   I am pretty certain we do not disagree on this.

 Richard

>> ...
>> Richard Riehle
>> richard@adaworks.com
>> http://www.adaworks.com

-- ======================= Original Example Appended Here =======================
>> 
>> I fully agree that the private type is underused for this purpose.
>> However, you will need to declare the arithmetic and logical
>> operators for a private type.  This is the ideal place for using
>> a nested Ops package to restrict the set of operators to exactly
>> those you want available in your design.
>> 
>> package P is
 
>>    type T is private;
>>    -- operations on T
>>    package Ops is
>>      function ">" (L, R : T) return Boolean;
>>      function "+" (L, R : T) return T;
>>    end Ops;
>> end P;
>> 
>> Now, use P.Ops makes sense and exports only the operators the
>> designer feels are appropriate but still restricts them to an
>> Ops package.  Of course, if they were not in the nested Ops package,
>> one could still invoke the "use type" clause.  In the end, I think it
>> it will be a matter of preference rather than a matter of which is
>> better.