TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
AdaWorks <[log in to unmask]>
Reply To:
Wed, 15 Apr 1998 18:53:57 -0700
TEXT/PLAIN (77 lines)
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
  subunit level.

>    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
  that extreme.

  [ 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

Richard Riehle
[log in to unmask]