On Mon, 2 Feb 1998, Swietanowski Artur wrote:
> Phillip Helbig wrote:
> > WW Schulz wrote:
> > > My view is somewhat different. This issue [interface -
> > > implementation separation] is and should remain a compiler
> > > problem. The code contains all the necessary information to construct
> > > the public interface which the compiler can use to check and determine
> > > whether the interface has been changed. The user should not be bothered
> > > to write an extra interface which will add to the workload and be
> > > error-prone. Interface checking is a perfect job for an automatic tool.
> >
> > I strongly agree. If the information is already there, requiring extra
> > work from the programmer is unnecessary and, as you point out, is an
> > additional source of potential error.
>
> The assertion that interface - implementation separation *must* cause
> code duplication is, AKAIK, false.
At least, nearly all proposals over the last months required a duplication of
some code, viz the interface. ADA95, Modula-3 require to write the interface
separately, i.e. code duplication.
The remaining proposals says the code is enough, this requires a smarter compiler
than is on offer today (not that much smarter).
>
> > > c) Privileged Access to internal and private details.
> > > This becomes very important for larger or more complicated codes.
> > > Fortran allows only PUBLIC or PRIVATE but does not provide anything
> > > more fine-grained. One could easily extend PRIVATE to PRIVATE(accesslist)
> > > where accesslist is a list of names of modules that have privileged
> > > access with the shortcuts PRIVATE(NONE) = PRIVATE, PRIVATE(ALL) = PUBLIC.
>
> May look good from the outside, but is probably as dangerous as C++
> friend classes and functions. For sure, it breaks the i-i separation.
> Also, requires changes in the module when new procedures / modules
> are created that are to have the privileged access. Promotes a messy
> programming style.
I think you are overly pessimistic here. Adding more fine-grained control
does not require more revision of code than is currently necessary, probably
less. The case where this is needed is typically a situation where two modules
have to know more about each other than they can under current rules but
they should be kept separately for other important reasons.
An example is MODULE SPARSE_VECTOR and MODULE SPARSE_MATRIX. For reasons of
efficiency both need to know more about the particular implementation, e.g.
about the storage form since just using procedures is inefficient,
while the public interface should remain rather abstract.
> A student of mine use the 'friend' mechanism in
> such a way, that he made everything in all the classes private, and
> then made all classes friends to each other.
>
> I do see the need of a fine grained access control. The merit of
> the proposal above is the ability to trace all possible dependencies
> when changing the internal workings of the module. The problem is:
> writing new code requires constantly revising the old one, even if
> the revision is trivial.
What it comes down to is a good design, one certainly has to think harder
before committing to a particular module (or type) design.
Philip Helbig's original question tried to get some answers on this from us.
It is difficult to answer. I am still refining my codes, splitting or joining
or reorganizing modules to get a better design. Sometimes it's easy to say
this belongs into a module, sometimes the current rules make it very difficult.
Looking at the code of other people can be useful (if you understand their code).
Cheers,
WWS
-----------------------------------------------------------------------
| Werner W Schulz |
| Dept of Chemistry email: [log in to unmask] |
| University of Cambridge Phone: (+44) (0)1223 336 502 |
| Lensfield Road Secretary: 1223 336 338 |
| Cambridge CB2 1EW Fax: 1223 336 536 |
| United Kingdom WWW: |
-----------------------------------------------------------------------
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
