Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!mcvax!kth!sunic!liuida!mikpa
From: mikpa@massormetrix.ida.liu.se (Mikael Patel)
Newsgroups: comp.lang.forth
Subject: Re: Encapsulation and visibility in Forth
Message-ID: <1319@massormetrix.ida.liu.se>
Date: 3 Aug 89 18:38:29 GMT
References: <8908031600.AA27902@jade.berkeley.edu>
Organization: Dept. of Info. and Comp. Science, Univ. of Linkoping, Sweden
Lines: 58

Hi, thanks for you answer to my question on encapsulation and visibility
in Forth. I had forgot all together about "beheading" as I have never
implemented such a function because of the same reasons you describe.

I'll try to explain the notion of encapsulation and visibility. In
languages such as Modula, C++, and Ada, it is possible to define an
interface between the outside world (the programmer using a module)
and the internal working of a module. This is used mostly to 
minimize the number of 'logical' interconnection between section
of a program, i.e., modules, if you like. The main idea is that
by defining the interface the implementation is allowed to change
without effecting the rest of the program.

One of the most over-used examples is a stack for which one defines
three procedures, initiate, push and pop, and then it may be implemented
in a number of fashions, i.e., lists, vector, tree etc.

An other more realistic example is the definition of a heap for
dynamically allocated memory. The basic interface to the heap could
be for instance, allocate and free, but the internal structure to
manage the heap may contain a number of lists etc. Allowing access 
to words that manipulate the heaps internals may corrupt its contents 
and would make the program that uses the heap very dependent on this
implementation (say that you know what you are doing).

How would you go around realizing this in Forth? As I see it, or at
least saw it before you reminded me about "beheading", there isn't a 
real basic mechanism for this. I'd like to do something like:

vocabulary heap

heap definitions

variable free-list private
variable free-size private

: find-free-block ( -- ) .... ; private
: link-in-free-block ( -- ) .... ; private

: allocate ( size -- ptr) .... find-free-block .... ; 
: free ( ptr -- flag) .... link-in-free-block .... ;

forth only

The "private" after the internal variables and functions would hide the
words if the vocabulary was not "current" so that when it was in context
only "allocate" and "free" are visible, and if you where going to do 
something that effected the "hidden" parts you would have to write it 
in this implementation.

The other two words I suggested where to create more control over the
mode dependency. Very few Forth implementations have this visibility
control and instead words such as "if" have to do the verification
of state (mode) themselves with words like "?comp" and "?exec".

Mikael

Sorry about the spelling of encapsulation. Seems like my Swedish tongue
caught me again.