On Wed, 15 Apr 1998, Robert I. Eachus wrote:
> Let see if I can make it simple... If you have a "maverick" operation
> that doesn't really belong to any type, and doesn't have any related
> operations, that unit should be a library subprogram.
Interesting phrase, "maverick operation." When considered in that way
it is difficult to disagree with the underlying assertion regarding the
inadvisability of with clauses for subunits.
I certainly do not advocate the proliferation of maverick operations
squirreled away in subunits. Also, I think I do understand the issues of
coupling and cohesion pretty well. The addition of child and private
child units to Ada 95 has helped to solve many knotty coupling
problems that we sometimes had to live with under Ada 83. In particular,
the very problem of subunit context clauses usually disappears
That being said, it is not always the case that subunit doesn't
belong to any type (I assume you mean, defined within that package).
Sometimes the subunit may have parameters of the package's main
type but require the resources of some utility package for its full
[ snipped some stuff here ]
> Of course, the right answer is that they go away. You partition out the
> operations of the abstraction and if necessary add them to the interface
> for the type. Then the maverick subprogram can be put into the program
> library as a subprogram, not a subunit.
If it is a maverick subprogram, I would agree. The case I am describing
is the simple case of a subprogram which is an operation of the type
but requires some little utility for its implementation. In this
situation, it seems appropriate to push the context clause to the
> So to me, any with clauses that apply to only one subprogram in the body
> are very suspect, and almost always indicate a design flaw.
The expression, "almost always" might be correct. Unfortunately, some
will interpret this as a "Thou shalt not have context clauses for a
subunit." I am fairly sure you would not want to suggest something
[ snipped some of Robert's good examples here ]
> ... So I am willing to make an exception
> for Unchecked_Conversion. But that's it.
That is what worries me. I agree that this should be rarely used, but
I would be a little more flexible.
> Any other with that applies to only one subprogram indicates poor cohesion,
> or that some type doesn't export a needed operation.
1) It may, indeed, export a needed operation, and may require
some external service to complete that operation.
2) It may also indicate poor cohesion, often will, and may be the
best way to accomplish the chore at hand. Unfortunately, even
with our best attempts to abide by the laws of coupling and
cohesion, we sometimes have to tresspass against them in the
interest of making the software do what is intended.
This argumnent is reminiscent of the "never use a goto statement."
I have not personally used a goto in years, but the last time I
did, it seemed the correct choice.
Thanks for your repsonse on this, Robert. I suspect we agree quite
closely on the need for careful design, including low-coupling and
high-cohesion. I would not want maverick subprograms in my design
[log in to unmask]