Re: Usage of Interfaces with Ada 95

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

Matthew Heaney wrote:

> Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> 
>> This is not the point! The point is, that i like to setup a
>> repository of concepts, which is specialized when it is used.
>> For example, the iterator (or enumerator) is a very general
>> concept which requieres basicaly the following methods
>> 
>>     First          - Return the first element
>>     Next           - Fetch the next element
>>     HasMoreElement - Check if there is more
>> 
>> 
>> By introducing a set of concepts i like to standarize the coding.
> 
> Again, your use of the term "concept" is unfortunate, because that
> already has a specific meaning, which is that it is something *not* in
> code.
I am not sure, but may be a better term would be pattern? Any way what
is your understanding of a concept?

> Code may reify a concept, but a concept by itself it not code.  If you
> want to standardize the coding, then do so!  But that is completely
> orthogonal to the idea of a concept.

Why are these thing orthogonal? I think a resonable large set of 
patterns (including interface) will keep most of the developers to 
develope there own world of interfaces (e.g. for iterators etc). Reusing 
the development patterns, which are resembled by interfaces, will 
also reduce the complexity of code by standarization the used interfaces,
which on the other hands will make it easier to learn how to use
a piece of code.

Again the iterator is nice example. For example if you take a group
of developers you will find an agreement that something like an iterator
is nessecary. But if you let them build there code independently, you
will find that all are using iterators on various but with slightly 
different interfaces. I my example i like to provide a package enumerator
where the developer X can put in his data type, but the gerneric package
forces him to implement the interface for his data type and nothing 
else. If the semantic of this interface is simple, it will be mutch 
easier for somebody else to maintain the code written on this concept.

>
> For example, all the containers and iterators in the Charles library
> reify your iterator concept above.  So what's the problem?  That library
> does exactly what you want, which is to iterate over the elements in a
> container.

This is true, actually i am not so mutch interested in containers etc, they
are simple a test object for my idea.

> Charles, the STL, and the Ada predefined I/O packages are all designed
> using static polymorphism. You seem to want to use dynamic
> polymorphism.  Why?  If static polymorophism does the job, what are you
> complaining about?
This is a good question. May be i need to rethink my position on this,
since the idea arises from my Java experience.

Regards
   M.Erdmann