Re: Separation of IF and Imp: process issue?

[Samuel Mize <smize@link.com>]

Patrick Doyle wrote:
> 
> In article <JSA.97Sep8150207@alexandria.organon.com>,
> Jon S Anthony <jsa@alexandria.organon.com> wrote:
...
> But let me ask you about one thing you said...
> 
> P.C does not inherit anything from P.  So what is the advantage of
> creating a child spec versus a whole new spec?

The child can see into the private part of the parent package.

This has to do with a package being a "module" (a collection of
things) rather than being a class definition.

A common example is an OS interface provided as a group of packages,
one for the file system, one for time utilities, etc.  They are all
children of a parent package that ONLY has private elements --
the items that the OS packages need to share.

The children can see and use these private variables, constants
and subprograms, but the client using one or more OS interface
packages cannot get at them.

The interface is broken up into many child packages so the user can
limit the amount of code "with"ed into the program.  If you only
need the current time, you don't have to bring in the entire OS
interface.


> When I said "properties" I meant interface properties, like what
> functions they implement and whatever other properties Ada allows
> you to declare in a package spec.  Whatever interfacing properties
> the spec declares, the body must posess.  To me, this smacks of
> inheritance.

If you only have a hammer, everything smacks of being a nail.

I realize that some people believe that the object-oriented view
subsumes all others, and no other paradigm SHOULD be used.  Ada was
not designed with this view.  For us, when doing non-object-oriented
coding, it's confusing to refer to "classes" and "deferred classes"
and "inheritance," especially if we ARE using object-oriented design
and coding methods elsewhere in our code.

We are doing something other than inheritance.  It can be modeled
with inheritance, just as everything done in Eiffel can be modeled
with straight functional assembly code (proof by existence: any
Eiffel compiler).  But non-object-oriented design methods use
other concepts than inheritance, and these are only confused by
being jammed into object-oriented terms.


> The way I see it, a deferred class sets forth some interface properties--
> the same kinds of properties as a spec file, and more--which its
> subclasses must posess.  To me, it's exactly the same situation
> between spec files and implementation files.

For packages that are classes, yes.

> Patrick Doyle
> doylep@ecf.utoronto.ca

Sam Mize