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: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: kennel@nospam.lyapunov.ucsd.edu (Matt Kennel (Remove 'NOSPAM' to reply)) Subject: Re: Separation of IF and Imp: process issue? Date: 1997/09/06 Message-ID: #1/1 X-Deja-AN: 270114179 References: <33E9ADE9.4709@flash.net> Organization: University of California at San Diego Reply-To: kennel@NOSPAMlyapunov.ucsd.edu Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-06T00:00:00+00:00 List-Id: On Thu, 04 Sep 1997 23:13:23 -0800, Matthew Heaney wrote: :In article , doylep@ecf.toronto.edu (Patrick :Doyle) wrote: : :>>But this is not quite the same thing as the relationship between a module :>>specification and its body. :> :> 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? : :True, an abstract superclass would specify the characteristics common to :every subclass in that derivation tree, but an interface file ("package :spec") describes the characteristics of a specific class. For example, :given an abstract queue superclass: : < long example> :But now it's not so obvious how to separate the changes made to the bodies :of the operations from the contract itself. Just think how much simpler it :is using existing configuration management technology to freeze a :specification, if it's a different text file from the text file containing :the body. I know. And the abstract class may also be in a separate file. In the case that you described, there would be TWO abstract classes in Eiffel. One would write a QUEUE abstract class, a BALKING_QUEUE abstract class (the 'spec' of the concrete), and a concrete BALKING_QUEUE_IMPLEMENTED_WITH_ARRAYS_BY_MBK class. It may happen to be the only subtype of BALKING_QUEUE. But so what? What is the problem? :By putting spec and body together, the configuration management :tool has to be smart enough to determine which part is the specification of :the routines and which is the body - much more sophistication than a CM :tool that need only treat everything as mere text. : :The change affects only the Balking_Queue subclass - not the abstract :superclass. That's why I'm not clear how freezing the spec of the root :type really solves anything. Yes, clients who manipulate classwide queue :objects, ie : :procedure Op (Queue : in out Root_Queue'Class) is ... : :would have a guarantee about the characteristics available for objects of :type Root_Queue'Class, if the abstract superclass were frozen, but I'm :talking about a client who depends on behavior specific to a balking queue: : : The_Queue : Balking_Queue; : ... : Remove_Item (From => The_Queue, At_The_Position => N); : : :It just seems simpler to have a different text file for the spec. That way :changes to the body can be made with impunity, and the compiler will check :that you haven't changed the contract in any way (because the contract is :kept separate). I am not disagreeing one bit about that. I'm saying that it sure seems like an Eiffel/Sather abstract class can do exactly that with the same clean mechanism used for subtype conformance since the ideas are almost the same. :There are probably some Eiffel subtleties that I've missed, but I hope I've :been able to explicate the Ada philosophy with respect to separation of :spec and body. In other words, Eiffel can separate the spec from the body too: such a point is fundamental in OOSC. Ada and Eiffel have the same underlying virtuous motives, but my personal opinion is that the Eiffel solution is cleaner and less bureaucratic. I'm wondering if there is some major issue that Ada addresses in this regard that Eiffel does not. It may be the case, but having spec and body in separate files is not a distinction between the languages. -- * Matthew B. Kennel/Institute for Nonlinear Science, UCSD * * According to California Assembly Bill 3320, it is now a criminal offense * to solicit any goods or services by email to a CA resident without * providing the business's legal name and complete street address. *