mikpa@massormetrix.ida.liu.se (Mikael Patel) (08/04/89)
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.
wmb@SUN.COM (08/04/89)
One technique I have used: For each "module", create two vocabularies, one for the visible words in the module, and one for the private words. The private vocabulary is contained within the public vocabulary. That way, you see the private words only if you want to. For example, I wrote a DOS-compatible file system in Forth. The interface words for the file system were contained within a vocabulary "dosfiles" . Within the "dosfiles" vocabulary, there was another vocabulary named "doshidden" , which contained the implementation factors. Mitch