Usage of Interfaces with Ada 95

Usage of Interfaces with Ada 95

[Michael Erdmann]

Dear all,

i like to provide a package of elementary interfaces providing some 
basic concepts on which a application is build, for example a
so called Enumeration type

generic
   type Data_Type is private;

package Interface.Enumeration is

   type Object is abstract tagged null record;

   function HasMoreElements(
      This : in Object ) return Boolean is abstract;

   procedure Next(
      This   : in out Object;
      Result : out Data_Type) is abstract;

end Interface.Enumeration;

because Ada does not provide an elementary object as e.g. java
this package has to be provided as an generic making the use 
of the package a little bit complicated.

.....
  type Enumerator is private;
.....
  procedure Next(
     This   : in out Enumerator;
     Result : out  Data_Type );
.....

private
  package Reader is new Interface.Enumeration( Data_Type );

  type Enumerator is new Reader.Object with record
          Next : Element_Access := null;
       end record;


The whole thing becomes more and more complicated for other
concepts e.g. a Dictionary which involves two types.

I am realy wondering if there is a better (simpler) way of
providing such a concept library?


Regards
   M.Erdmann

Re: Usage of Interfaces with Ada 95

[chris]

Michael Erdmann wrote:

> 
> I am realy wondering if there is a better (simpler) way of
> providing such a concept library?

That reminds me, will Ada0Y have a way to include operations in generics 
for interfaces.  Something like

generic
   type x is blah_interface with private use blah_package?
package xxx is

end xxx;

instead of

generic
   type x is blah_interface with private;
   with procedure blah_proc;
   with function blah_func return blah_interface;
package xxx is

end xxx;

I meant to ask in an earlier thread, but forgot.

Re: Usage of Interfaces with Ada 95

[Hyman Rosen]

Michael Erdmann wrote:
> i like to provide a package of elementary interfaces providing some 
> basic concepts on which a application is build, for example a
> so called Enumeration type

Using inheritance for iterators is silly and wrong,
since the base iterator class can't express anything
about what it iterates over, or what type it returns.

Go see the Charles library for how to do it right.

DK, this is your cue :-)

Re: Usage of Interfaces with Ada 95

[Michael Erdmann]

Hyman Rosen wrote:

> Michael Erdmann wrote:
>> i like to provide a package of elementary interfaces providing some
>> basic concepts on which a application is build, for example a
>> so called Enumeration type
> 
> Using inheritance for iterators is silly and wrong,
> since the base iterator class can't express anything
> about what it iterates over, or what type it returns.

This is the reason why it is abstract and a generic.
> 
> Go see the Charles library for how to do it right.
> 
> DK, this is your cue :-)

The point is that in java i am able to provide an interface
which is called IIterator and use this interface in different 
implementation, but it is the same interface which has to be 
understood by the programmer only once!

Michael

Re: Usage of Interfaces with Ada 95

[Hyman Rosen]

Michael Erdmann wrote:
> The point is that in java i am able to provide an interface
> which is called IIterator and use this interface in different 
> implementation, but it is the same interface which has to be 
> understood by the programmer only once!

No; what does your iterator return when you ask for the
next element? An Object, I presume. Then the client must
cast it to the type he thinks it is. That's a terrible
interface, and certainly not worth copying.

Re: Usage of Interfaces with Ada 95

[Michael Erdmann]

Hyman Rosen wrote:

> Michael Erdmann wrote:
>> The point is that in java i am able to provide an interface
>> which is called IIterator and use this interface in different
>> implementation, but it is the same interface which has to be
>> understood by the programmer only once!
> 
> No; what does your iterator return when you ask for the
> next element? An Object, I presume. Then the client must
> cast it to the type he thinks it is. That's a terrible
> interface, and certainly not worth copying.

This is exactly what happens in a lot of java code i have 
seem. They are using somthing like

    if(  x.istanceOf(...) ) {
    }

I feel the same way, this is a stupid aproach which also
leads to stability problems when something changes in the 
environment and new types are introduced.

The consequence is, that i have to stick with the somewhat 
complicated process:

  1. Define a concept as a generic, eg.

     generic
        type aType ....;

     package ... is 

        type Object is abstract ...

        funtion Get(This : Object) return aType is abstract; 
        .. other methods defining the concept
    end package;

  2. Provide a specific application of the concept to a 
     data type to avoid the cast issue.
     (lets call this an specefic interface)

  3. Use the specific interface within an application.

Maybe i need drop my original idea completley. The idea was to 
provide a set of interfaces which are allowing to develop
software based on concepts (patterns). The Enumeration is 
such a concept beside of a lot of other patterns.
My hope was/is to simplyfy code by using standard patterns.


Regards
   M.Erdmann

Re: Usage of Interfaces with Ada 95

[Matthew Heaney]

Michael Erdmann <Michael.Erdmann@snafu.de> writes:

> Maybe i need drop my original idea completley. The idea was to provide
> a set of interfaces which are allowing to develop software based on
> concepts (patterns). The Enumeration is such a concept beside of a lot
> of other patterns.  My hope was/is to simplyfy code by using standard
> patterns.

What's wrong with generic algoriths?  An "enumeration" (an unfortunate
term, given that is it already has a very specific meaning in Ada)
smells a lot like an "iterator," so I hvae to ask why you don't simply
go that way:

generic
   type Iterator_Type is private;
   with function Succ (Iterator : Iterator_Type)
      return Iterator_Type is <>;
   with procedure Process (Iterator : Iterator_Type) is <>;
   ...
procedure Generic_Algorithms (First, Back : Iterator_Type);

But perhaps you're trying to do something else?  It wasn't clear from
your example.  As far I can tell the language already does everything
you need, so no language change is required.

Re: Usage of Interfaces with Ada 95

[Matthew Heaney]

Hyman Rosen <hyrosen@mail.com> writes:

> Using inheritance for iterators is silly and wrong, since the base
> iterator class can't express anything about what it iterates over, or
> what type it returns.
> 
> Go see the Charles library for how to do it right.

Amen to that.  He needs a generic algorithm, but just doesn't know how
to express it in Ada.  Use the Source, Luke!

<http://home.earthlink.net/~matthewjheaney/charles/>

Re: Usage of Interfaces with Ada 95

[Michael Erdmann]

Matthew Heaney wrote:

> Hyman Rosen <hyrosen@mail.com> writes:
> 
>> Using inheritance for iterators is silly and wrong, since the base
>> iterator class can't express anything about what it iterates over, or
>> what type it returns.
>> 
>> Go see the Charles library for how to do it right.
> 
> Amen to that.  He needs a generic algorithm, but just doesn't know how
> to express it in Ada.  Use the Source, Luke!
> 
> <http://home.earthlink.net/~matthewjheaney/charles/>
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 
conding. For example the arugment between two developers already
start with naming of the method HasMoreElements. In order to avoid 
such discussions i like to introduce interface class as for example 
in java. 
The nice thing about java interfaces is that all classes
are derived from the Object class. This is not the case in Ada,
there i dont have such a thing as the Object class. And it seems
that i need use generics making the handling a little bit 
complicated because:

   1. Define a generic package with your abstract interface
      which has a type as argument.
   2. Specialize the interface for the requiered type,
      which is still abstract.
   3. Implement classes around the specialzed types.

I am looking for a way of avoiding step 1.



 

Re: Usage of Interfaces with Ada 95

[Matthew Heaney]

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.

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.

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.

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?

Re: Usage of Interfaces with Ada 95

[Michael Erdmann]

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

Re: Usage of Interfaces with Ada 95

[Simon Wright]

Matthew Heaney <matthewjheaney@earthlink.net> writes:

> 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

This will have a problem in Ada since you'll be treating the iterator
as an in out parameter to what otherwise looks like a function.

> >     Next           - Fetch the next element
> >     HasMoreElement - Check if there is more
> > 
> > 
> > By introducing a set of concepts i like to standarize the coding.

> 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.

And so do Booch Component iterators, which are abstract, and which of
course are much more like what all English-speaking programmers bar
those who also speak STL understand by Iterator than the STL ones
which Charles has adopted. I just have to get that dig in. And there
are some on the ARG who have similar views. We shall have to see how
it goes! Personally I have no problem at all with what the STL does,
just some of the names it's adopted for the concepts ..

Re: Usage of Interfaces with Ada 95

[Robert I. Eachus]

Michael Erdmann wrote:

> The nice thing about java interfaces is that all classes
> are derived from the Object class.

Your opinion.  I like having unrelated classes unrelated.

>                                    This is not the case in Ada,
> there i dont have such a thing as the Object class. And it seems
> that i need use generics making the handling a little bit 
> complicated because:
> 
>    1. Define a generic package with your abstract interface
>       which has a type as argument...

> I am looking for a way of avoiding step 1.

The way to avoid step 1 is to use a standard package library like
Charles.

 >    2. Specialize the interface for the required type,
 >       which is still abstract.
 >    3. Implement classes around the specialzed types.

In the Ada world we often take a different view of what is going on 
here.  You want to have some object class, call it Foo, and a container 
class.  In most object oriented languages you do that by inheriting from 
both Foo and a container class, say Queue.  So you create a 
Foo_with_Queues class.

In Ada, you can do that.  Or you can Keep Foo separate from the 
Queue_of_Foo class.  That way you can put objects of type Foo in a 
Queue_of_Foo and get them back out again. If you also have Tree_of_Foo, 
you can take an item from a Tree_of_Foo and put it in a Queue_of_Foo 
without having the class Foo, as such, as a subclass of either.  (Or you 
can have a single object in several different queues.)

Yes, if you are constantly putting Foo objects into and out of queues, 
and an object is allowed to be in only one queue at a time, having the 
necessary links as part of the object state is more efficient.  If 
instead Foo objects are found in several different containers or types 
of containers, having the container implementation separate from the 
object state is a big win.

Which style is better for your application is highly dependent on the 
application.  But if the language only gives you a hammer, you implement 
everything with nails.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Usage of Interfaces with Ada 95

[Matthew Heaney]

Michael Erdmann <Michael.Erdmann@snafu.de> writes:

> 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.

You still haven't groked the static polymorphism idea.

If I have the following generic algorithm:

  generic
     type Iterator_Type is private;
     with function Succ (Iterator : Iterator_Type)
       return Iterator_Type is <>;
     with procedure Process (Iterator : Iterator_Type) is <>;
     with function "=" (L, R : Iterator_Type)
       return Boolean is <>;
  procedure Generic_Algorithm (First, Back : Iterator_Type);

Then of course this is going to check how iterators are declared by
independent developers -- as soon as he tries to instantiate the generic
algorithm.  Any iterator any developer builds must conform to this
logical interface.

You want the do the check at the time of compilation of the declaration
of the iterator type.  I don't.  I defer the check until the time of
compilation of the instantiation of the generic algorithm.

If you understand the difference then you understand static
polymorphism.  Forget about Java because it's only going to confuse you.

One consequence of defering the check is that is doesn't matter if
independent developers come up with different iterator interfaces.  The
generic algorithm doesn't care, because it only cares about the logical
properties of the iterator, not the syntax of the declaration.

The algorithm above is written with Charles iterators in mind.  So
naturally it's simple to instantiate it.  Let's start with a list:

  package List_Types is new Charles.Lists.Double.Unbounded (ET);

  procedure Op (List : List_Types.Container_Type) is

     procedure Process (I : List_Types.Iterator_Type) is
        E : ET := Element (I);
     begin
        ... -- do whatever
     end;

     procedure Algorithm is
        new Generic_Algorithm (Iterator_Type);  -- accept defaults
  begin
     Algorithm (First (List), Back (List));
  end;


Now let's use the generic algorithm on a vector, which doesn't have an
iterator type:

   package Vector_Types is new Charles.Vectors.Unbounded
     (Index_Typey => IT,
      Element_Type => ET);

   procedure Op (Vector : Vector_Type.Container_Type) is

      procedure Process (I : IT) is
         E : ET := Element (Vector, Index => I);
      begin
         ... -- do whatever
      end;

     procedure Algorithm is
        new Generic_Algorithm
             (Iterator_Type => IT,  -- index subtype
              Succ          => IT'Succ);
  begin
     Algorithm (First (Vector), Back (Vector));
  end;


Now let's use the generic algorithm again, on an array, which doesn't
have an iterator type either:

   procedure Op (A : Array_Subtype) is

      procedure Process (I : IT) is
         E : ET renames A (I);
      begin
         ... -- do whatever
      end;

     procedure Algorithm is
        new Generic_Algorithm
             (Iterator_Type => IT,  -- index subtype
              Succ          => IT'Succ);
  begin
     Algorithm (First => A'First, Back => A'First + A'Length);
  end;


In your original example, your preferred iterator style is to have
operations First, Next, and HasMoreElement.  Let's use the generic
algorithm above on your iterator:

   procedure Op (C : in CT) is

      procedure Process (I : IT) is
        E : ET := Get_Element (I); -- or whatever
      begin
        ... -- do whatever
      end;

      function Is_Done (Iter, Back : IT) return Boolean is
      begin
         return not HasMoreElement (Iter);  -- ignore Back
      end;
     
      procedure Algorithm is
        new Generic_Algorithm
             (Iterator_Type => IT,  -- index subtype
              Succ          => Next,
              "="           => Is_Done);

      Dummy : IT;

   begin -- Op

      Algorithm (First (C), Back => Dummy);

   end Op;


So here you have 4 different containers, each with a different iteration
scheme.  Yet there is only a single generic algorithm.

If you understand how this all works then you will understand static
polymorphism.  Forget about Java because it's only going to confuse you.

Re: Usage of Interfaces with Ada 95

[Matthew Heaney]

Simon Wright <simon@pushface.org> writes:

> > Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> > 
> > >     First          - Return the first element
> 
> This will have a problem in Ada since you'll be treating the iterator
> as an in out parameter to what otherwise looks like a function.

Actually I didn't catch that.  I assumed First returned an iterator
value.  But you're right, it looks like this function has side-effect.

Re: Usage of Interfaces with Ada 95

[Matthew Heaney]

Simon Wright <simon@pushface.org> writes:

> And so do Booch Component iterators, which are abstract, and which of
> course are much more like what all English-speaking programmers bar
> those who also speak STL understand by Iterator than the STL ones
> which Charles has adopted. I just have to get that dig in. And there
> are some on the ARG who have similar views. We shall have to see how
> it goes! Personally I have no problem at all with what the STL does,
> just some of the names it's adopted for the concepts ..

I don't know why you'd think this.  I didn't make this up.  Read the
chapter titled Iterator in the design patterns book by Gamma et al.  The
English-speaking world (and the German-speaking world too, apparently)
has settled on the terms "container" and "iterator."  And "factory
method."  And "visitor."  And whatever.  So stop fighting it and read
Gamma!

Re: Usage of Interfaces with Ada 95

[George Shapovalov]

Ok, after reading through this:

Michael Erdmann wrote:
>  The idea was to
> provide a set of interfaces which are allowing to develop
> software based on concepts (patterns). The Enumeration is
> such a concept beside of a lot of other patterns.
> My hope was/is to simplyfy code by using standard patterns.

I thought of something that seems similar :).

I suspect what you really are looking for is what's proposed in:
AI-251/07 "Abstract interfaces to provide multiple inheritance".
 for Ada 200Y.
This particular one seems to be under 
"The intention for the following AIs was approved but they require a
rewrite", so there is hope ;).
You can take a look for example here:
http://www.ada-auth.org/ai-files/minutes/min-0306.html#AI251

George

Re: Usage of Interfaces with Ada 95

[Hyman Rosen]

Robert I. Eachus wrote:
> Your opinion.  I like having unrelated classes unrelated.

Me too. How unfortunate that in Ada, to get abilities similar
to C++'s constructors, destructors, and assignment operator
you must inherit from a common base class!

Re: Usage of Interfaces with Ada 95

[Matthew Heaney]

Simon Wright <simon@pushface.org> wrote in message news:<x7vy8w8rg9h.fsf@smaug.pushface.org>...
> Matthew Heaney <matthewjheaney@earthlink.net> writes:
> 
> > 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.
> 
> And so do Booch Component iterators, which are abstract, and which of
> course are much more like what all English-speaking programmers bar
> those who also speak STL understand by Iterator than the STL ones
> which Charles has adopted. I just have to get that dig in. And there
> are some on the ARG who have similar views. We shall have to see how
> it goes! Personally I have no problem at all with what the STL does,
> just some of the names it's adopted for the concepts ..

Actually, I just pulled out my copy of Software Components With Ada by
Grady Booch, which has a copyright of 1987.  His discussion of active
vs. passive iterators begins on p. 157.

The name of his active iterator type is "Iterator," declared right
there on p. 158.

So this is an old idea.  I must say I find it very odd that the
maintainer of the Booch Components is unfamiliar with the iterators
used by the Booch Components!

Re: Usage of Interfaces with Ada 95

[Stephen Leake]

Michael Erdmann <Michael.Erdmann@snafu.de> writes:

> Matthew Heaney wrote:
> > Amen to that.  He needs a generic algorithm, but just doesn't know how
> > to express it in Ada.  Use the Source, Luke!
> > 
> > <http://home.earthlink.net/~matthewjheaney/charles/>
> 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

Perhaps you would like the alternate approach to this whole idea that
I used in SAL: http://www.toadmail.com/~ada_wizard/ada/sal.html.
There, a "container" is not a rigidly defined type, it is just a
concept. Containers are anything that can be used with the set of
generic algorithm packages.

I'm not clear SAL is what you want, but it is different enough from
Charles and Booch Components that it may give you some ideas on how to
express what you want in Ada.

I suspect part of what you want will be provided by Ada0Y Interfaces.

> The nice thing about java interfaces is that all classes
> are derived from the Object class. 

Hmm, that's not what I do in SAL, so you probably won't like it. I
believe Charles works that way, though.

> This is not the case in Ada, there i dont have such a thing as the
> Object class. 

But can declare one, and use it everywhere.

> And it seems that i need use generics making the handling a little
> bit complicated because:
> 
>    1. Define a generic package with your abstract interface
>       which has a type as argument.

You have to declare your abstract interface somewhere, even in Java.

>    2. Specialize the interface for the requiered type,
>       which is still abstract.

>    3. Implement classes around the specialzed types.
> 
> I am looking for a way of avoiding step 1.

I'm confused. Perhaps you can give an example of what you want in
Java, and then show your attempt to implement it in Ada. That would
make this discussion much clearer.

-- 
-- Stephe

PS I'm on vacation for a week starting tomorrow, so I may respond to
posts this week.

Re: Usage of Interfaces with Ada 95

[Georg Bauhaus]

>>>>> "Matthew" == Matthew Heaney <matthewjheaney@earthlink.net> writes:

: Simon Wright <simon@pushface.org> writes:
:: Personally I have no problem at all with what the
:: STL does, just some of the names it's adopted for the concepts ..

: The English-speaking world (and the German-speaking world too,
: apparently) has settled on the terms "container" and "iterator."

As for German, that settling (which is a fashion rather, I'd say) is
certainly not an argument, if you care about language. (And I'm glad
to have seen a Deprecated names package in Charles, so some language
work is being done ;-) People seem to have differing views of what
"iterator" should mean, but that aside, might we suspect that there is
some Russian English in Stepanov's work?

For example, every other "new computer word" here (in Germany) has
been coined out of helpless (and probalby thoughtless) ignorance (no
rebuke intended), being pressed for a word.  There is "gedownloadet"
which is there because people haven't bothered to think about what
"download" means, or even just look it up in an older computer
dictionary. If you know that "geladen" is a perfect match for
"loaded", why not use "geladen", as has been done until a few years
ago?

Personally, I'm impressed with learned language use which is both
idiomatic and traditional, though not outdated, and that is not just
common in current computer speak, or, hip if I may say so.  The former
I find is the case in Burns' and Wellings' "Concurrency in Ada".
Sometimes their way of employing natural language is as different from
that found in other computer textbooks as it is helpful in
understanding.

It might be fun if you mix two languages and grammars like Martin
Luther and friends did with Latin and German. However, Luther's
translation of the reference book of Christian religion is an attempt
to avoid Pigeon German. Still another language's influence might
add to expressive power of a language. Which version of "Iterator"
is better in that respect?

: And "factory method."  And "visitor."  And whatever.  So stop
: fighting it and read Gamma!

who is German.

("Refactoring" is becoming popular as well. Search the Google
c.l.ada archives for "refactoring", and "pompous" :-)

You will certainly have noticed that English is not a language I know
well enough to be allowed these paragraphs.  Still, sometimes reading
STL speak (or, though to a lesser extent, Booch speak) is as if by
analogy I have to groke the new fictitious linear algebra term
"samegestaltism" which is then just barely related to "homomorphism".

Maybe it is a good thing to have "slightly new words" for the
new STL way?


Georg

Re: Usage of Interfaces with Ada 95

[Georg Bauhaus]

>>>>> "Georg" == Georg Bauhaus <georg@strudel.futureapps.de> writes:

: : And "factory method."  And "visitor."  And whatever.  So stop :
: fighting it and read Gamma!

: who is German.

speaks German. Sorry.



: Georg

Re: Usage of Interfaces with Ada 95

[Simon Wright]

Matthew Heaney <matthewjheaney@earthlink.net> writes:

> Simon Wright <simon@pushface.org> writes:
> 
> > And so do Booch Component iterators, which are abstract, and which of
> > course are much more like what all English-speaking programmers bar
> > those who also speak STL understand by Iterator than the STL ones
> > which Charles has adopted. I just have to get that dig in. And there
> > are some on the ARG who have similar views. We shall have to see how
> > it goes! Personally I have no problem at all with what the STL does,
> > just some of the names it's adopted for the concepts ..
> 
> I don't know why you'd think this.  I didn't make this up.  Read the
> chapter titled Iterator in the design patterns book by Gamma et al.  The
> English-speaking world (and the German-speaking world too, apparently)
> has settled on the terms "container" and "iterator."  And "factory
> method."  And "visitor."  And whatever.  So stop fighting it and read
> Gamma!

You know that I am perfectly well aware of what Iterators are for.

I have just checked the GoF and Grady's book, and both of them are a
lot closer (IMO) to what the BCs mean by Iterator than what the STL
does.

The STL means something quite like "designator of one end of a
half-open range".

I am not a C++ speaker, but

  for (i = cont.start(); i != cont.oneAfterTheEnd(); i++)

is *not* the way the GoF, or Grady, describe it.

Re: Usage of Interfaces with Ada 95

[Matthew Heaney]

Simon Wright <simon@pushface.org> writes:

> The STL means something quite like "designator of one end of a
> half-open range".
> 
> I am not a C++ speaker, but
> 
>   for (i = cont.start(); i != cont.oneAfterTheEnd(); i++)
> 
> is *not* the way the GoF, or Grady, describe it.

I disagree that this is any different.  Let's rewrite the generic
algorithm that I posted earlier, to use Simon's preferred syntax:

   generic
      type IT is private;
      with function Succ (I : IT) return IT is <>;
      with procedure Process (I : IT) is <>;
      with function Is_Done (I : IT) return Boolean is <>;
   procedure Generic_Algorithm (First : in IT);

Now let's use the a Charles list (say) to instantiate the Simon
algorithm:

   procedure Op (List : in List_Subtype) is

      procedure Process (I : IT) is ...;

      function Is_Done (I : IT) return Boolean is
      begin
         return I /= Back (List);
      end;

      procedure Algorithm is
        new Generic_Algorithm (IT, Succ, Process, Is_Done);
   begin
      Algorithm (First (List));
   end;

It's equivalent to what I showed yesterday.  There is no difference
between "STL" iterator and "Booch" iterator, except for syntax.

In fact you could easily convert Grady's active iterator implementation
of p. 158 to use Stepanov syntax, by simply declaring a constant of type
Iterator (equal to null internally) and providing an equality operator
for Iterator.

It's all the same.

Re: Usage of Interfaces with Ada 95

[Matthew Heaney]

Stephen Leake <Stephe.Leake@nasa.gov> writes:

> Hmm, that's not what I do in SAL, so you probably won't like it. I
> believe Charles works that way, though.

Oh god no.  I dislike inheritance.  The container types in Charles are
all fully independent types, declared this way:

   type Container_Type is private;

There is no public derivation anywhere in Charles.

Re: Usage of Interfaces with Ada 95

[Robert I. Eachus]

Hyman Rosen wrote:

> Me too. How unfortunate that in Ada, to get abilities similar
> to C++'s constructors, destructors, and assignment operator
> you must inherit from a common base class!

Nope!  Mix-ins to the rescue.  You can mix a component of a type derived 
from Controlled (or Limited Controlled) into an uncontrolled type.  In 
fact, the base type doesn't even need to be tagged.  Access 
discriminants can be used to allow the operations of the controlled 
component to access the entire record.  (But if you use this style you 
will find that the access discriminants are not often needed.)

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Usage of Interfaces with Ada 95

[Michael Erdmann]

Matthew Heaney wrote:

> Michael Erdmann <Michael.Erdmann@snafu.de> writes:
> 
>> ........ 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.
> 
> You still haven't groked the static polymorphism idea.
> 
> If I have the following generic algorithm:
> 
>   generic
>      type Iterator_Type is private;
>      with function Succ (Iterator : Iterator_Type)
>        return Iterator_Type is <>;
>      with procedure Process (Iterator : Iterator_Type) is <>;
>      with function "=" (L, R : Iterator_Type)
>        return Boolean is <>;
>   procedure Generic_Algorithm (First, Back : Iterator_Type);
> 
> Then of course this is going to check how iterators are declared by
> independent developers -- as soon as he tries to instantiate the generic
> algorithm.  Any iterator any developer builds must conform to this
> logical interface.

Thanks for your example!

I assume, that the procedure Generic_Algorithm is containing some kind 
of implementation of an iterator based on the input parameters of the 
generic?

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?
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. 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.

Regards
    M.Erdmann

Re: Usage of Interfaces with Ada 95

[Preben Randhol]

On 2003-09-29, Georg Bauhaus <georg@strudel.futureapps.de> wrote:
>
> For example, every other "new computer word" here (in Germany) has
> been coined out of helpless (and probalby thoughtless) ignorance (no
> rebuke intended), being pressed for a word.  There is "gedownloadet"
> which is there because people haven't bothered to think about what
> "download" means, or even just look it up in an older computer
> dictionary. If you know that "geladen" is a perfect match for
> "loaded", why not use "geladen", as has been done until a few years
> ago?

I see the same in Norwegian: downloadet (=downloaded) attachment, savet
(=saved) In stead of: Lastet ned, vedlegg and lagret. However there seem
to be more and more using the Norwegian words and I think it has to do
with that more and more people have Norwegian in they desktop OS. I mean
in the old days everything was English and in order to explain to
somebody what to do you had to use English words so he/she would find
the correct menus. Now when you have the menus in Norwegian one use the
Norwegian names.

Preben

RE: Usage of Interfaces with Ada 95

[Mário Amado Alves]

> >   generic
> >      type Iterator_Type is private;
> >      with function Succ (Iterator : Iterator_Type)
> >        return Iterator_Type is <>;
> >      with procedure Process (Iterator : Iterator_Type) is <>;
> >      with function "=" (L, R : Iterator_Type)
> >        return Boolean is <>;
> >   procedure Generic_Algorithm (First, Back : Iterator_Type);
>
> 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. 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.

Somebody has to implement at some point. I think the example come short.
There is a 'zero-implementation' way to specify interfaces in Ada:
signature packages. The signature package for the stuff above is

generic
  type Iterator_Type is private;
  with function Succ (Iterator : Iterator_Type) return Iterator_Type is
<>;
  with procedure Process (Iterator : Iterator_Type) is <>;
  with function "=" (L, R : Iterator_Type) return Boolean is <>;
  with procedure Generic_Algorithm (First, Back : Iterator_Type) is <>;
package Signature is end;

Re: Usage of Interfaces with Ada 95

[Matthew Heaney]

Michael Erdmann <Michael.Erdmann@snafu.de> writes:

> I assume, that the procedure Generic_Algorithm is containing some kind
> of implementation of an iterator based on the input parameters of the
> generic?

Well, technically the iterator itself is implemented elsewhere.  The
generic algorithm doesn't care.  It just uses the iterator, like this:

procedure Generic_Algorithm (First, Back : IT) is
   I : IT := First;
begin
   while I /= Back loop
      ... -- whatever
      Process (I);
      ... -- whatever
      I := Succ (I);
   end loop;
end Generic_Algorithm;


> 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).

Re: Usage of Interfaces with Ada 95

[Marin David Condic]

What do you have against inheritance? It would seem useful for a 
container to be inherited from Controlled so that it can guarantee 
finalization. I don't find anything inherently evil in inheritance - 
what's the problem?

MDC

Matthew Heaney wrote:
> 
> 
> Oh god no.  I dislike inheritance.  The container types in Charles are
> all fully independent types, declared this way:
> 
>    type Container_Type is private;
> 
> There is no public derivation anywhere in Charles.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================

Re: Usage of Interfaces with Ada 95

[Hyman Rosen]

Robert I. Eachus wrote:
> Nope!  Mix-ins to the rescue.  You can mix a component of a type derived 
> from Controlled (or Limited Controlled) into an uncontrolled type.  In 
> fact, the base type doesn't even need to be tagged.  Access 
> discriminants can be used to allow the operations of the controlled 
> component to access the entire record.  (But if you use this style you 
> will find that the access discriminants are not often needed.)

Let me see if I have this right. I believe that in Ada, controlled
types can be declared only at library level, correct? So if the
mix-in is going to do something with its containing object, then
doesn't the type of the containing object have to be declared at
library level as well? This means that the awkward inheritance-based
model of controlled drives the package structure, which seems like a
bad idea to me.

I don't see that mix-ins gain you very much in this case anyway.
If you're going to have a mix-in with an access discriminant,
why not just make the containing type controlled?
I suppose it's because you may already need to be part of another
inheritance hierarchy, which just brings back the MI question.

Re: Usage of Interfaces with Ada 95

[Matthew Heaney]

Matthew Heaney <matthewjheaney@earthlink.net> wrote in message news:<u3cefgq26.fsf@earthlink.net>...
>
> Now let's use the a Charles list (say) to instantiate the Simon
> algorithm:
> 
>    procedure Op (List : in List_Subtype) is
> 
>       procedure Process (I : IT) is ...;
> 
>       function Is_Done (I : IT) return Boolean is
>       begin
>          return I /= Back (List);
>       end;

oops!  Of course that should have been:

   function Is_Done (I : IT) return Boolean is
   begin
      return I = Back (List);
   end;

Re: Usage of Interfaces with Ada 95

[Preben Randhol]

On 2003-09-30, Matthew Heaney <mheaney@on2.com> wrote:
> oops!  Of course that should have been:
>
>    function Is_Done (I : IT) return Boolean is
>    begin
>       return I = Back (List);
>    end;

Alternatively, rename the previous function to:

   function Is_Not_Done (I : IT) return Boolean is
 
;-)
 
Preben

Re: Usage of Interfaces with Ada 95

[Michael Erdmann]

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

Re: Usage of Interfaces with Ada 95

[Robert I. Eachus]

Hyman Rosen wrote:

> Let me see if I have this right. I believe that in Ada, controlled
> types can be declared only at library level, correct? So if the
> mix-in is going to do something with its containing object, then
> doesn't the type of the containing object have to be declared at
> library level as well? This means that the awkward inheritance-based
> model of controlled drives the package structure, which seems like a
> bad idea to me.

There are only two times I tend to put type declarations inside 
procedures:  In small examples where it is nice to be able to tell 
someone to compile a file and run it, and when the main procedure is a 
manager for a complex application, and I need to enumerate the parts:
type Pass is (Syntax_Analysis, Semantic_Analysis, Optimizer, 
Code_Generation);

So other than trivial examples, ALL tagged types I create are at the 
library level.  It doesn't matter if the package containing the is 
nested six deep within other packages, as long as the outermost package 
is at the library level, all the nested packages are also.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Usage of Interfaces with Ada 95

[Hyman Rosen]

Robert I. Eachus wrote:
> So other than trivial examples, ALL tagged types I create are at the 
> library level.

If a generic package defines a controlled type, can that
package be instantiated at non-library level?

Re: Usage of Interfaces with Ada 95

[Matthew Heaney]

Marin David Condic <nobody@noplace.com> writes:

> What do you have against inheritance? It would seem useful for a
> container to be inherited from Controlled so that it can guarantee
> finalization. I don't find anything inherently evil in inheritance -
> what's the problem?

Well of course all the unbounded forms privately derive from Controlled.
There would be no way to automatically reclaim memory otherwise.

We were talking about interfaces, which means some kind of public
inheritance.

Re: Usage of Interfaces with Ada 95

[Robert I. Eachus]

Hyman Rosen wrote:

> If a generic package defines a controlled type, can that
> package be instantiated at non-library level?

If you read 3.10.2 you will learn more than you want to know about 
accessability levels.  The important rule for this case is in 3.9.1(3):    "

-- 
                                           Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Usage of Interfaces with Ada 95

[Robert I. Eachus]

(Please excuse the partial message, I hit the wrong key when pasting.)

Hyman Rosen wrote:

> If a generic package defines a controlled type, can that
> package be instantiated at non-library level?

If you read 3.10.2 you will learn more than you want to know about 
accessability levels.  However, the important rule for this case is in 
3.9.1(3):   "The accessibility level (see 3.10.2) of a record extension 
shall not be statically deeper than that of its parent type. In addition 
to the places where Legality Rules normally apply (see 12.3), these 
rules apply also in the private part of an instance of a generic unit."

But why would you want to instantiate a generic package that declares an 
explicitly tagged type other than as a library unit or in another package?

-- 
                                          Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Usage of Interfaces with Ada 95

[Hyman Rosen]

Robert I. Eachus wrote:
> But why would you want to instantiate a generic package that declares an 
> explicitly tagged type other than as a library unit or in another package?

Because the generic parameters that I want to supply are
the results of some computation? If I'm writing a Charles
algorithm as a procedure, might I not need to instantiate
some generic packages inside the procedure as part of the
work I'm doing?

Re: Usage of Interfaces with Ada 95

[Robert I. Eachus]

Hyman Rosen wrote:

> Because the generic parameters that I want to supply are
> the results of some computation? If I'm writing a Charles
> algorithm as a procedure, might I not need to instantiate
> some generic packages inside the procedure as part of the
> work I'm doing?

I wish I knew of an online source for "Nesting in Ada is for the Birds." 
by Lori A. Clarke, et. al.  Ah Ha! The ACM Digital Library now has it: 
http://portal.acm.org/citation.cfm?id=807944&jmp=abstract&coll=portal&dl=ACM

This is from 1980, and to say that it is accepted gospel in the Ada 
community is probably an understatement.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig

Re: Usage of Interfaces with Ada 95

[Matthew Heaney]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1065014507.632467@master.nyc.kbcfp.com>...
> Robert I. Eachus wrote:
> > But why would you want to instantiate a generic package that declares an 
> > explicitly tagged type other than as a library unit or in another package?
> 
> Because the generic parameters that I want to supply are
> the results of some computation? If I'm writing a Charles
> algorithm as a procedure, might I not need to instantiate
> some generic packages inside the procedure as part of the
> work I'm doing?

In that case a bounded form might be more appropriate.  Bounded forms
don't derive from Controlled so there is no problem with nesting
levels.

The next release of Charles will have better support for bounded
forms.  I've been too busy with AI-302-02 to release any updates.  My
immediate plan is to prepare submissions (tutorials + paper) for
Ada-Europe 2004.