Re: Usage of Interfaces with Ada 95

[Michael Erdmann <Michael.Erdmann@snafu.de>]

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