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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,309015504ed37ff0 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-30 12:49:26 PST Path: archiver1.google.com!news2.google.com!sn-xit-02!sn-xit-04!sn-xit-06!sn-xit-05!sn-xit-08!supernews.com!news.tele.dk!news.tele.dk!small.news.tele.dk!eusc.inter.net!news.eusc.inter.net!boavista.snafu.de!news From: Michael Erdmann Newsgroups: comp.lang.ada Subject: Re: Usage of Interfaces with Ada 95 Date: Tue, 30 Sep 2003 21:58:10 +0200 Organization: gnade.sourceforge.net Message-ID: References: <1064595326.831730@master.nyc.kbcfp.com> <4nii41-067.ln1@boavista.snafu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.eusc.inter.net 1064951365 14506 213.73.65.189 (30 Sep 2003 19:49:25 GMT) X-Complaints-To: abuse@eusc.inter.net User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:32 Date: 2003-09-30T21:58:10+02:00 List-Id: Matthew Heaney wrote: >> You are right, this provides a standarized interface, but i guess the >> procedure Generic_Algorithm contains some kind of implementation of an >> iteration based on the methods specified in the input? > > The Generic_Algorithm contains some kind of implementation of an > algorithm, not an iterator. The algorithm uses the iterator to > implement the algorithm. > > >>I think the is a different view on the topic by defining a >>functionality of an interface, providing a generic implementation which >>defines the interface for the programmer. > > Yes, the generic algorithm specifies what it requires of the iterator. > Any iterator satisfying those (logical) properties can be used, as we > saw in the example. > > >> This was exactly what i dont like to do. I dont like to spent the >>effort of breaking down a concept into a generic implementation. This >>is the reason why i like to use interfaces. > > Well, that's not static polymorphism. It's dynamic polymorphism -- or > at least it's type derivation. > > I much don't like inheritance, but you seem prefer it. Vive la > difference, comme on dit en France (et aux Etats Unis, aussi). I am not so mutch in inheritance, static/non static polymorphism etc... The idea originated some time ago. Normally in my open source projects i split up the source code into the following parts (by subdirectories): ./src - All sources of the basic functionality of the project ./util - A place to put all utility packages but does not on the project ./apps - All application drivers for the project I have made the experience this is theoretical quite simple to move the utility package between projects but what is causing useless effort is the evolution of basics concepts. When i complete one projects and find in the next project some kind of bug it is normally difficult to find out how this component fits into the old context since my understanding of the properties of a certain concept (e.g. Iterator) has changed since then. Therefor i like to standarize coding to this extend that at least basic concepts are standarized by introducing a directory ./intf which contains abstract interfaces defining such basic concepts. The idea to put there so called non functional interfaces which means zero code. If i have to extend/change a component when porting it between projects, let the compiler find out what has changed since i am compiling the code against the interfaces of the old project. I thought that abstract types would be best choice :-/ On the second hand i intended to achive a consistent look and feel over all projects. The idea is not to achieve some kind of "wold best code" but simply to reduce my efforts and make maintenace cheeper. I guess static polymorphism a one way of doing it. The charme about it is that you already break down the interfaces into some generic procedure implementation, which documents by it self what the concept is intended to do. In my original idea, this was not the case since i wanted to write down an interface specification where you need to document the semantics of this interface explicitly, which naturaly poses the problem the actual implementation my deviate completly from the deocumentation resulting in strange behaviours and the compiler does not has any chance to help you. I will give it a trail. Regards M.Erdmann