🚀 go-pugleaf

In article <5750@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>>From simpson@poseidon.uucp (Scott Simpson):
>> Notice that once I added state, my operations no longer work.  There are
>> a few ways to get around this limitation:
>> 
>> 	1) Repeat operations at each level.
>
>   This is precisely what I had in mind.  Note: "a new package serves
>   as an interface which hides both the calls to the old package and
>   the new code which was added on top of it".

I assume you mean you wish to incrementally wrap packages in this manner.
If this is the case, you have to create new functions that are in 
one-to-one correspondence with the package at the previous level.  This
is error prone.  Also, you will have to *add code* to handle the added
state.  In an OOPL neither do you repeat operations nor add code.
You simply specify the relationship that one type is a subtype of another.
This relationship is language enforced and language supported.  It is not
by convention.

>   when you wish to add a layer of abstraction; simply have a program ask you
>   for the name of the new data type(s) and automatically generate a higher-
>   level package which implements itself through calls to the lower-level
>   packages.  Q.E.D., as they say in mathematics...

Writing such a program is not necessary in an OOPL.  How will this
automatic code generation program know how to write code for the added
state?  Do you know of such a program?
	Scott Simpson
	TRW Space and Defense Sector
	oberon!trwarcadia!simpson  	(UUCP)
	trwarcadia!simpson@usc.edu	(Internet)