Re: Package reformatting tool availability

[Mark Lundquist <mark@rational.com>]

Richard D Riehle wrote:

> In article <37D542F9.3C6C9F4D@res.raytheon.com>,
>         Andy Askey <askeya@res.raytheon.com> wrote:
>
> >a different criteria for grouping types within packages.  It appears
> >that there is some rule of thumb that only about 30-50 types can be
> >placed in one package.  When more types are created, there is an obvious
> >need for another package.
>



> One of the problems with the Ada package is how it encourages such
> practices.

I wouldn't agree that Ada "encourages" this.  Ada allows it.  So does C++.
You can define any number of classes is in a file, as many as you like
(similarly, a Java package can contain arbitrary class definitions).

While packages may seem to contain primitives in the same sense that classes
contain member functions, the C++ analogue of a package is not a class.  If
anything, the (poor) C++ analogue of an Ada package is the "file", as in
("header file" and "implementation file").  There is another aspect in which
the analogue of the Ada package is the C++ namespace.

>  This reflects one of the benefits of C++ or Eiffel:  each
> C++ class is a type.

That's more of a definition than a statement, so I'm not getting what the
benefits are...

>  If I still understand object-oriented modeling, a
> package should export one main type with appropriate operations on that
> type. The structure of the type is hidden from a client of the package.
> The package may also export some supplementary types such as enumeration
> types, etc.
>
> Does this create too many packages?  What is too many?  Robert Dewar
> is fond of reminding us that Ada is designed to be more readable than
> writeable. That is one of goals of encapsulation and information hiding,
> isn't it?

Actually, I would say not.  The goals of encapsulation have to do with
abstraction (and whether abstraction leads to greater readability is sort of
in the eye of the beholder, and it involves lifecycle considerations too).
Readability is the goal of clean syntax.

> I thought Brad Balfour and Ed Seidiwitz long ago put the issue
> of global Ada type packages to rest.
>
> Also, with the advent of generic formal package parameters, child library
> units, private child units, and the new renaming options, Ada 95 makes
> it easy to design small packages that support the behavior of one type
> In fact, used correctly, these features of Ada 95 put Ada ahead of some
> other languages such as C++ where type <=> module <=> class.
>

 I'd say Ada95 is ahead even without considering those features, but...:-)

Are you saying that Ada's separation of typing and modularity is a weakness
(as you seemed to be  saying earlier), but that this weakness is overcome by
the correct use of certain other features?

I believe that the conflation of type and module into one construct is a
mistake -- unfortunately, that's the "idea package" in which most of us
(myself included) first encountered OO, thanks to Alan Kay and Adele
Goldberg.  At the time, this idea was a great experiment (not the only great
experiment of the Smalltalk environment, of course -- the other was the
window-mouse MMI paradigm).  And paradoxically, it was necessary that OO hit
the streets in the radicalized, class-oriented form, because the computing
community really did need to have its collective brain washed in order to
understand and accept the value of the underlying, true OO concepts
(encapsulation, inheritance, polymorphism, and for all but the most
extreme "purist", genericity).  But the attempt to fundamentally define and
forumulate OO in terms of the class construct is moribund.

I've been wanting to write an article about the myth of "pure OO" and the
brokenness of class-centered OO... just haven't been able to make the time
to do it.  Plus, I don't know if the world is ready... :-) :-)


--

Mark Lundquist
Senior Software Engineer
Rational Software
Development Solutions Business Unit
UNIX Suites Group
Aloha, OR, USA