Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!wiley!trwarcadia!simpson From: simpson@trwarcadia.uucp (Scott Simpson) Newsgroups: comp.sw.components Subject: Re: Inheritance vs. component efficienc Message-ID: <5044@wiley.UUCP> Date: 14 Jun 89 14:26:19 GMT References: <5021@wiley.UUCP> <5750@hubcap.clemson.edu> Sender: news@wiley.UUCP Reply-To: simpson@trwarcadia.UUCP (Scott Simpson) Organization: TRW Arcadia Project, Redondo Beach, CA Lines: 32 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)