Re: Is Apex dead as an environment for Ada & Java?

["Samuel T. Harris" <sam_harris@hso.link.com>]

jim_snead wrote:
> 
> In article <38441AAE.29B2D8@hso.link.com>, "Samuel T. Harris"
> <sam_harris@hso.link.com> wrote:
> > One way to eliminate circular dependencies is to insure
> > each interface is in a separate subsystem from its users.
> > For instance, say I have two major code collections called
> > X and Y. They both interface with each other, so X provides
> > an interface which Y uses and Y provides an interface which
> > X uses. If X's interface in packaged with X's code and similarly
> > for Y, then we have a mutual import dependency.
> > However, if I split the interfaces out into separate subsystems,
> > say X_Iface, X_Model, Y_Iface, and Y_Model, then I eliminate
> > the circular dependencies. If all models have a separate Iface
> > subsystem, then I never get circular dependencies no matter
> > what the interface topology. This also alows a natural release
> > strategy of releasing updated interfaces independently. This
> > allows all models to progress to the new interfaces in succession.
> > This architecture is very flexible to a variety of scheduling
> > paradims.
> 
> So specs go into the IFace and bodies go into the Model subsystems?
> 

One could do that, and I have considered this idea on several
occasions to limit recompilation impact imposed by new releases,
but that is not what I meant. The interface is a different package
from the model. The interface spec and body units go into a
separate subsystem from the model spec and body units.

Since you mentioned the idea of putting unit specs and bodies
into separate subsystems, I'll elaborate on this as well.
Even the advanced incremental compiler provided with Apex
provides little benefit when a new release is being made.
Conventional code organization keeps the spec and body of
a unit in the same place. On the surface, this seems a
natural organizational scheme. However, when a new release
is made because of strictly body changes, a new spec is
also released. This causes an unneccesary compilation impact.

Looking deeper into the problem, we can realize that the
separation of the spec and body in Ada provides an
equivalent opportunity to separate in code organization.
Keeping the specs and bodies in separate subsystems yields
some important benefits.

1) A view only needs to import spec views. Body views need
not be imported at all. Body views do need to be listed
in the link_with_configuration. One can envision a customization
which manages link_imports just like, but separate from,
regular view imports.

2) I can change the link_imports at will and suffer no
compilation effects (unless inline subprograms are in use).
I only have to relink. This allows me to rapidly try
different implementation options using a single set of
package specs.

This organization scheme also suffers from the following
disadvantages.

1) The separation of spec and body into two different
areas makes it clumsy for the developer. Two naturally
intimate units do not reside in the same place. Of course
this issue is mitigated with the superb navigation facilities
and can be handled by using "working" subsystems whose views
use symbolic links to "collect" related stuff together into
one place.

2) Immature code in the early stages of development will
not realize the benefits noted above. The specs of such
code change nearly as often as the bodies. Only mature
code with stable specs are candidates for this scheme.

I have given this issue much thought over the years.
I originally wanted to simulate the old R1000 facility
of spec views vs load views. A spec view had only
uint specifications. It could be related to many different
load views which had the unit bodies. The load view
also had specs, but they had to have the same content.
Since the spec view and load views were in the same
subsystem, this scheme did not suffer from the clumsiness
of their separation.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Scientific and Technical Systems
"If you can make it, We can fake it!"