* Usage of Interfaces with Ada 95 @ 2003-09-26 16:36 Michael Erdmann 2003-09-26 16:50 ` chris 2003-09-26 16:55 ` Hyman Rosen 0 siblings, 2 replies; 43+ messages in thread From: Michael Erdmann @ 2003-09-26 16:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-26 16:36 Usage of Interfaces with Ada 95 Michael Erdmann @ 2003-09-26 16:50 ` chris 2003-09-26 16:55 ` Hyman Rosen 1 sibling, 0 replies; 43+ messages in thread From: chris @ 2003-09-26 16:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-26 16:36 Usage of Interfaces with Ada 95 Michael Erdmann 2003-09-26 16:50 ` chris @ 2003-09-26 16:55 ` Hyman Rosen 2003-09-26 19:10 ` Michael Erdmann 2003-09-28 2:14 ` Matthew Heaney 1 sibling, 2 replies; 43+ messages in thread From: Hyman Rosen @ 2003-09-26 16:55 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-26 16:55 ` Hyman Rosen @ 2003-09-26 19:10 ` Michael Erdmann 2003-09-26 20:37 ` Hyman Rosen 2003-09-28 2:14 ` Matthew Heaney 1 sibling, 1 reply; 43+ messages in thread From: Michael Erdmann @ 2003-09-26 19:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-26 19:10 ` Michael Erdmann @ 2003-09-26 20:37 ` Hyman Rosen 2003-09-27 15:05 ` Michael Erdmann 0 siblings, 1 reply; 43+ messages in thread From: Hyman Rosen @ 2003-09-26 20:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-26 20:37 ` Hyman Rosen @ 2003-09-27 15:05 ` Michael Erdmann 2003-09-28 2:11 ` Matthew Heaney 2003-09-29 2:25 ` George Shapovalov 0 siblings, 2 replies; 43+ messages in thread From: Michael Erdmann @ 2003-09-27 15:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-27 15:05 ` Michael Erdmann @ 2003-09-28 2:11 ` Matthew Heaney 2003-09-29 2:25 ` George Shapovalov 1 sibling, 0 replies; 43+ messages in thread From: Matthew Heaney @ 2003-09-28 2:11 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-27 15:05 ` Michael Erdmann 2003-09-28 2:11 ` Matthew Heaney @ 2003-09-29 2:25 ` George Shapovalov 1 sibling, 0 replies; 43+ messages in thread From: George Shapovalov @ 2003-09-29 2:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-26 16:55 ` Hyman Rosen 2003-09-26 19:10 ` Michael Erdmann @ 2003-09-28 2:14 ` Matthew Heaney 2003-09-28 8:28 ` Michael Erdmann 1 sibling, 1 reply; 43+ messages in thread From: Matthew Heaney @ 2003-09-28 2:14 UTC (permalink / raw) 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/> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 2:14 ` Matthew Heaney @ 2003-09-28 8:28 ` Michael Erdmann 2003-09-28 14:33 ` Matthew Heaney ` (2 more replies) 0 siblings, 3 replies; 43+ messages in thread From: Michael Erdmann @ 2003-09-28 8:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 8:28 ` Michael Erdmann @ 2003-09-28 14:33 ` Matthew Heaney 2003-09-28 15:09 ` Michael Erdmann 2003-09-28 17:10 ` Simon Wright 2003-09-28 18:22 ` Robert I. Eachus 2003-09-29 14:52 ` Stephen Leake 2 siblings, 2 replies; 43+ messages in thread From: Matthew Heaney @ 2003-09-28 14:33 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 14:33 ` Matthew Heaney @ 2003-09-28 15:09 ` Michael Erdmann 2003-09-28 21:50 ` Matthew Heaney 2003-09-28 17:10 ` Simon Wright 1 sibling, 1 reply; 43+ messages in thread From: Michael Erdmann @ 2003-09-28 15:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 15:09 ` Michael Erdmann @ 2003-09-28 21:50 ` Matthew Heaney 2003-09-30 4:57 ` Michael Erdmann 0 siblings, 1 reply; 43+ messages in thread From: Matthew Heaney @ 2003-09-28 21:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 21:50 ` Matthew Heaney @ 2003-09-30 4:57 ` Michael Erdmann 2003-09-30 10:02 ` Mário Amado Alves 2003-09-30 12:31 ` Matthew Heaney 0 siblings, 2 replies; 43+ messages in thread From: Michael Erdmann @ 2003-09-30 4:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: Usage of Interfaces with Ada 95 2003-09-30 4:57 ` Michael Erdmann @ 2003-09-30 10:02 ` Mário Amado Alves 2003-09-30 12:31 ` Matthew Heaney 1 sibling, 0 replies; 43+ messages in thread From: Mário Amado Alves @ 2003-09-30 10:02 UTC (permalink / raw) To: comp.lang.ada > > 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; ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-30 4:57 ` Michael Erdmann 2003-09-30 10:02 ` Mário Amado Alves @ 2003-09-30 12:31 ` Matthew Heaney 2003-09-30 19:58 ` Michael Erdmann 1 sibling, 1 reply; 43+ messages in thread From: Matthew Heaney @ 2003-09-30 12:31 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-30 12:31 ` Matthew Heaney @ 2003-09-30 19:58 ` Michael Erdmann 0 siblings, 0 replies; 43+ messages in thread From: Michael Erdmann @ 2003-09-30 19:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 14:33 ` Matthew Heaney 2003-09-28 15:09 ` Michael Erdmann @ 2003-09-28 17:10 ` Simon Wright 2003-09-28 21:52 ` Matthew Heaney ` (2 more replies) 1 sibling, 3 replies; 43+ messages in thread From: Simon Wright @ 2003-09-28 17:10 UTC (permalink / raw) 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 .. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 17:10 ` Simon Wright @ 2003-09-28 21:52 ` Matthew Heaney 2003-09-28 21:58 ` Matthew Heaney 2003-09-29 13:49 ` Matthew Heaney 2 siblings, 0 replies; 43+ messages in thread From: Matthew Heaney @ 2003-09-28 21:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 17:10 ` Simon Wright 2003-09-28 21:52 ` Matthew Heaney @ 2003-09-28 21:58 ` Matthew Heaney 2003-09-29 19:37 ` Georg Bauhaus 2003-09-29 20:11 ` Simon Wright 2003-09-29 13:49 ` Matthew Heaney 2 siblings, 2 replies; 43+ messages in thread From: Matthew Heaney @ 2003-09-28 21:58 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 21:58 ` Matthew Heaney @ 2003-09-29 19:37 ` Georg Bauhaus 2003-09-29 19:45 ` Georg Bauhaus 2003-09-30 7:10 ` Preben Randhol 2003-09-29 20:11 ` Simon Wright 1 sibling, 2 replies; 43+ messages in thread From: Georg Bauhaus @ 2003-09-29 19:37 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-29 19:37 ` Georg Bauhaus @ 2003-09-29 19:45 ` Georg Bauhaus 2003-09-30 7:10 ` Preben Randhol 1 sibling, 0 replies; 43+ messages in thread From: Georg Bauhaus @ 2003-09-29 19:45 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-29 19:37 ` Georg Bauhaus 2003-09-29 19:45 ` Georg Bauhaus @ 2003-09-30 7:10 ` Preben Randhol 1 sibling, 0 replies; 43+ messages in thread From: Preben Randhol @ 2003-09-30 7:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 21:58 ` Matthew Heaney 2003-09-29 19:37 ` Georg Bauhaus @ 2003-09-29 20:11 ` Simon Wright 2003-09-29 22:56 ` Matthew Heaney 1 sibling, 1 reply; 43+ messages in thread From: Simon Wright @ 2003-09-29 20:11 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-29 20:11 ` Simon Wright @ 2003-09-29 22:56 ` Matthew Heaney 2003-09-30 14:53 ` Matthew Heaney 0 siblings, 1 reply; 43+ messages in thread From: Matthew Heaney @ 2003-09-29 22:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-29 22:56 ` Matthew Heaney @ 2003-09-30 14:53 ` Matthew Heaney 2003-09-30 16:13 ` Preben Randhol 0 siblings, 1 reply; 43+ messages in thread From: Matthew Heaney @ 2003-09-30 14:53 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-30 14:53 ` Matthew Heaney @ 2003-09-30 16:13 ` Preben Randhol 0 siblings, 0 replies; 43+ messages in thread From: Preben Randhol @ 2003-09-30 16:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 17:10 ` Simon Wright 2003-09-28 21:52 ` Matthew Heaney 2003-09-28 21:58 ` Matthew Heaney @ 2003-09-29 13:49 ` Matthew Heaney 2 siblings, 0 replies; 43+ messages in thread From: Matthew Heaney @ 2003-09-29 13:49 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 8:28 ` Michael Erdmann 2003-09-28 14:33 ` Matthew Heaney @ 2003-09-28 18:22 ` Robert I. Eachus 2003-09-29 3:02 ` Hyman Rosen 2003-09-29 14:52 ` Stephen Leake 2 siblings, 1 reply; 43+ messages in thread From: Robert I. Eachus @ 2003-09-28 18:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 18:22 ` Robert I. Eachus @ 2003-09-29 3:02 ` Hyman Rosen 2003-09-30 3:11 ` Robert I. Eachus 0 siblings, 1 reply; 43+ messages in thread From: Hyman Rosen @ 2003-09-29 3:02 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-29 3:02 ` Hyman Rosen @ 2003-09-30 3:11 ` Robert I. Eachus 2003-09-30 13:38 ` Hyman Rosen 0 siblings, 1 reply; 43+ messages in thread From: Robert I. Eachus @ 2003-09-30 3:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-30 3:11 ` Robert I. Eachus @ 2003-09-30 13:38 ` Hyman Rosen 2003-09-30 21:46 ` Robert I. Eachus 0 siblings, 1 reply; 43+ messages in thread From: Hyman Rosen @ 2003-09-30 13:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-30 13:38 ` Hyman Rosen @ 2003-09-30 21:46 ` Robert I. Eachus 2003-09-30 22:10 ` Hyman Rosen 0 siblings, 1 reply; 43+ messages in thread From: Robert I. Eachus @ 2003-09-30 21:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-30 21:46 ` Robert I. Eachus @ 2003-09-30 22:10 ` Hyman Rosen 2003-10-01 2:30 ` Robert I. Eachus 2003-10-01 2:41 ` Robert I. Eachus 0 siblings, 2 replies; 43+ messages in thread From: Hyman Rosen @ 2003-09-30 22:10 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-30 22:10 ` Hyman Rosen @ 2003-10-01 2:30 ` Robert I. Eachus 2003-10-01 2:41 ` Robert I. Eachus 1 sibling, 0 replies; 43+ messages in thread From: Robert I. Eachus @ 2003-10-01 2:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-30 22:10 ` Hyman Rosen 2003-10-01 2:30 ` Robert I. Eachus @ 2003-10-01 2:41 ` Robert I. Eachus 2003-10-01 13:21 ` Hyman Rosen 1 sibling, 1 reply; 43+ messages in thread From: Robert I. Eachus @ 2003-10-01 2:41 UTC (permalink / raw) (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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-10-01 2:41 ` Robert I. Eachus @ 2003-10-01 13:21 ` Hyman Rosen 2003-10-01 17:01 ` Robert I. Eachus 2003-10-01 18:46 ` Matthew Heaney 0 siblings, 2 replies; 43+ messages in thread From: Hyman Rosen @ 2003-10-01 13:21 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-10-01 13:21 ` Hyman Rosen @ 2003-10-01 17:01 ` Robert I. Eachus 2003-10-01 18:46 ` Matthew Heaney 1 sibling, 0 replies; 43+ messages in thread From: Robert I. Eachus @ 2003-10-01 17:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-10-01 13:21 ` Hyman Rosen 2003-10-01 17:01 ` Robert I. Eachus @ 2003-10-01 18:46 ` Matthew Heaney 1 sibling, 0 replies; 43+ messages in thread From: Matthew Heaney @ 2003-10-01 18:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-28 8:28 ` Michael Erdmann 2003-09-28 14:33 ` Matthew Heaney 2003-09-28 18:22 ` Robert I. Eachus @ 2003-09-29 14:52 ` Stephen Leake 2003-09-29 23:00 ` Matthew Heaney 2 siblings, 1 reply; 43+ messages in thread From: Stephen Leake @ 2003-09-29 14:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-29 14:52 ` Stephen Leake @ 2003-09-29 23:00 ` Matthew Heaney 2003-09-30 12:49 ` Marin David Condic 0 siblings, 1 reply; 43+ messages in thread From: Matthew Heaney @ 2003-09-29 23:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-29 23:00 ` Matthew Heaney @ 2003-09-30 12:49 ` Marin David Condic 2003-09-30 23:48 ` Matthew Heaney 0 siblings, 1 reply; 43+ messages in thread From: Marin David Condic @ 2003-09-30 12:49 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Usage of Interfaces with Ada 95 2003-09-30 12:49 ` Marin David Condic @ 2003-09-30 23:48 ` Matthew Heaney 0 siblings, 0 replies; 43+ messages in thread From: Matthew Heaney @ 2003-09-30 23:48 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2003-10-01 18:46 UTC | newest] Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-09-26 16:36 Usage of Interfaces with Ada 95 Michael Erdmann 2003-09-26 16:50 ` chris 2003-09-26 16:55 ` Hyman Rosen 2003-09-26 19:10 ` Michael Erdmann 2003-09-26 20:37 ` Hyman Rosen 2003-09-27 15:05 ` Michael Erdmann 2003-09-28 2:11 ` Matthew Heaney 2003-09-29 2:25 ` George Shapovalov 2003-09-28 2:14 ` Matthew Heaney 2003-09-28 8:28 ` Michael Erdmann 2003-09-28 14:33 ` Matthew Heaney 2003-09-28 15:09 ` Michael Erdmann 2003-09-28 21:50 ` Matthew Heaney 2003-09-30 4:57 ` Michael Erdmann 2003-09-30 10:02 ` Mário Amado Alves 2003-09-30 12:31 ` Matthew Heaney 2003-09-30 19:58 ` Michael Erdmann 2003-09-28 17:10 ` Simon Wright 2003-09-28 21:52 ` Matthew Heaney 2003-09-28 21:58 ` Matthew Heaney 2003-09-29 19:37 ` Georg Bauhaus 2003-09-29 19:45 ` Georg Bauhaus 2003-09-30 7:10 ` Preben Randhol 2003-09-29 20:11 ` Simon Wright 2003-09-29 22:56 ` Matthew Heaney 2003-09-30 14:53 ` Matthew Heaney 2003-09-30 16:13 ` Preben Randhol 2003-09-29 13:49 ` Matthew Heaney 2003-09-28 18:22 ` Robert I. Eachus 2003-09-29 3:02 ` Hyman Rosen 2003-09-30 3:11 ` Robert I. Eachus 2003-09-30 13:38 ` Hyman Rosen 2003-09-30 21:46 ` Robert I. Eachus 2003-09-30 22:10 ` Hyman Rosen 2003-10-01 2:30 ` Robert I. Eachus 2003-10-01 2:41 ` Robert I. Eachus 2003-10-01 13:21 ` Hyman Rosen 2003-10-01 17:01 ` Robert I. Eachus 2003-10-01 18:46 ` Matthew Heaney 2003-09-29 14:52 ` Stephen Leake 2003-09-29 23:00 ` Matthew Heaney 2003-09-30 12:49 ` Marin David Condic 2003-09-30 23:48 ` Matthew Heaney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox