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: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,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/05 Message-ID: <34106A26.4DC3@link.com>#1/1 X-Deja-AN: 270032409 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-05T00:00:00+00:00 List-Id: Jon S Anthony wrote: > > In article doylep@ecf.toronto.edu (Patrick Doyle) writes: > > > Ok, I'll boil my position down into one question: What does a separate > > interface file do for a class that an abstract superclass can't do? The structure of the question shows an assumption. Not all Ada packages are classes -- nor should they be. (I am assuming that an Eiffel "class" is an object-oriented construct exporting a data type that implements objects of that class.) In Ada we're often working with different paradigms. The classic example is a utility package exporting a bunch of math routines. This isn't a "class" unless you extend the concept of "class" until it loses all object-oriented significance, and becomes in essence an Ada package instead. (In languages without a packaging construct, this often happens.) Where a class structure is appropriate, you may well be right. However, it appears (from postings by another Eiffel user) that you are extending the meaning of the superclass concept, in essence creating a special-purpose idiom. Nothing wrong with that, they exist in every language. Ada directly supports this idiom because system partitioning and decomposition are extremely important in its intended domain. I would also point out, by the way, that it would be trivial to create a perl script (probably just an awk script) to generate an Ada spec from an Ada body in much the same way that Eiffel's short-form tool works. Subprogram declarations would be duplicated, constants and variables would be migrated to the spec and commented out of the body. Comments prior to each declaration would be copied, comments inside the subprograms would not. Comment flags would be used to mark things as being local-usage only (not to be copied to the spec). Nobody has done it, and nobody in the Ada community probably cares to do it, because we use the spec as an important design and communication tool. This is NOT to deride its importance or usefulness to the Eiffel community; it is only to say that we work in different paradigms, and in different ways, and for US the separate spec is very helpful. Sam Mize