From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: Samuel Mize Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/09 Message-ID: <3415828A.F51@link.com>#1/1 X-Deja-AN: 271025044 References: <33E9ADE9.4709@flash.net> Reply-To: smize@link.com Organization: Hughes Training Inc. Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-09T00:00:00+00:00 List-Id: Patrick Doyle wrote: > > In article , > Jon S Anthony wrote: ... > But let me ask you about one thing you said... > > P.C does not inherit anything from P. So what is the advantage of > creating a child spec versus a whole new spec? The child can see into the private part of the parent package. This has to do with a package being a "module" (a collection of things) rather than being a class definition. A common example is an OS interface provided as a group of packages, one for the file system, one for time utilities, etc. They are all children of a parent package that ONLY has private elements -- the items that the OS packages need to share. The children can see and use these private variables, constants and subprograms, but the client using one or more OS interface packages cannot get at them. The interface is broken up into many child packages so the user can limit the amount of code "with"ed into the program. If you only need the current time, you don't have to bring in the entire OS interface. > When I said "properties" I meant interface properties, like what > functions they implement and whatever other properties Ada allows > you to declare in a package spec. Whatever interfacing properties > the spec declares, the body must posess. To me, this smacks of > inheritance. If you only have a hammer, everything smacks of being a nail. I realize that some people believe that the object-oriented view subsumes all others, and no other paradigm SHOULD be used. Ada was not designed with this view. For us, when doing non-object-oriented coding, it's confusing to refer to "classes" and "deferred classes" and "inheritance," especially if we ARE using object-oriented design and coding methods elsewhere in our code. We are doing something other than inheritance. It can be modeled with inheritance, just as everything done in Eiffel can be modeled with straight functional assembly code (proof by existence: any Eiffel compiler). But non-object-oriented design methods use other concepts than inheritance, and these are only confused by being jammed into object-oriented terms. > The way I see it, a deferred class sets forth some interface properties-- > the same kinds of properties as a spec file, and more--which its > subclasses must posess. To me, it's exactly the same situation > between spec files and implementation files. For packages that are classes, yes. > Patrick Doyle > doylep@ecf.utoronto.ca Sam Mize