Re: Enforcing concepts in the language (was: Re: Implement Inheritance (Ada83)?)

[Jeff Seigle <jseigle@csci.csc.com>]

In article <D555G8.EIK@inmet.camb.inmet.com> brennan@panther.warm.inmet.com (William Brennan) writes:
>In article <3jiala$kqs@explorer.csc.com>,
>Jeff Seigle  <jseigle@csci.csc.com> wrote:
>>[...]
>>once the code is 
>>written there is no enforcement of your wonderful ideas, and the next
>>one to come along with a mod can stomp down all of your imaginary fences.
>
>And even having a design technique supported by the language is not enough.
>Almost all of the packages I have written over the past 5 years use 
>private types for data abstraction.  I have regularly seen occurences where
>some maintainer would come by, figure he/she didn't have immediate
>enough access to the type and move it into the visible part of the spec, 
>breaking the encapsulation, of course.  One can hear them muttering under 
>their breath: "What's this _private_ stuff for anyway, it's only getting in 
>my way!"

I have heard many programmers say right *over* their breath, "What's this 
private stuff for anyway, it's only getting in my way!"  I also heard one
programmer say, "This 'package' stuff is just making my life difficult."
This problem is one that always looms and no amount of design, language 
support, documentation, or general head-pounding can help.

(BTW the Fortran technique was to define a subroutine with the encapsulated
variables, then define an entry for each operation.  Each entry has to have
a return before the next entry declaration.  You aren't supposed to call the
subroutine, only the entries.  But there's no way to enforce the concept
in maintenance.)

Jeff