* Idiom for a class and an object in Ada @ 2004-10-18 11:47 Marin David Condic 2004-10-18 12:14 ` Martin Krischik ` (4 more replies) 0 siblings, 5 replies; 55+ messages in thread From: Marin David Condic @ 2004-10-18 11:47 UTC (permalink / raw) Suppose I have a class with one or a limited set of objects. The objects are "global" in the sense that they hang around from program startup thru the entire life of execution. An example would be an A/D Converter class - My little control box might have 3 or 4 A/Ds in it - they're always there and I want the data associated with them to be static (not declared on the stack.) Question: What is the preferred Ada idiom for defining such a creature? I have a package that defines the class - that contains the tagged type and any methods. I might: a) Declare the objects within that "class" package b) Declare the objects within some child package of the class package c) Declare the objects in some global "Here's all my static data" package (not very tidy) d) Declare the objects in the main program (not good if they are accessed by more than one task and also a kind of dumping ground) Does anybody have an opinion or experience with doing this? I know what I've done in the past, but I'm curious if there is any preferred method or idiom for this in the OO paradigm as applied to Ada? MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Power corrupts. Absolute power is kind of neat" -- John Lehman, Secretary of the Navy 1981-1987 ====================================================================== ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-18 11:47 Idiom for a class and an object in Ada Marin David Condic @ 2004-10-18 12:14 ` Martin Krischik 2004-10-18 19:40 ` Matthew Heaney 2004-10-19 12:59 ` Marin David Condic 2004-10-18 12:26 ` Marius Amado Alves ` (3 subsequent siblings) 4 siblings, 2 replies; 55+ messages in thread From: Martin Krischik @ 2004-10-18 12:14 UTC (permalink / raw) Marin David Condic wrote: > Suppose I have a class with one or a limited set of objects. The objects > are "global" in the sense that they hang around from program startup > thru the entire life of execution. An example would be an A/D Converter > class - My little control box might have 3 or 4 A/Ds in it - they're > always there and I want the data associated with them to be static (not > declared on the stack.) > > Question: What is the preferred Ada idiom for defining such a creature? > > I have a package that defines the class - that contains the tagged type > and any methods. I might: > > a) Declare the objects within that "class" package Yes, within the class body only. > b) Declare the objects within some child package of the class package If there are a lot of static data, use a private package. For both: When multi tasking is an issue use a protected type to secure access to the data. > c) Declare the objects in some global "Here's all my static data" > package (not very tidy) No. > d) Declare the objects in the main program (not good if they are > accessed by more than one task and also a kind of dumping ground) No as well. Each package has it > Does anybody have an opinion or experience with doing this? I know what > I've done in the past, but I'm curious if there is any preferred method > or idiom for this in the OO paradigm as applied to Ada? If you truly thing about OO you would us a singelton class. You know a class where only one instance exists. Within the singelton class (package body) you can either use class data or static data. It would not matter since is is all hidden inside the package body. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-18 12:14 ` Martin Krischik @ 2004-10-18 19:40 ` Matthew Heaney 2004-10-19 12:59 ` Marin David Condic 1 sibling, 0 replies; 55+ messages in thread From: Matthew Heaney @ 2004-10-18 19:40 UTC (permalink / raw) "Martin Krischik" <krischik@users.sourceforge.net> wrote in message news:9175719.eWmeGlFrVu@linux1.krischik.com... > Marin David Condic wrote: > >> Suppose I have a class with one or a limited set of objects. The objects >> are "global" in the sense that they hang around from program startup >> thru the entire life of execution. An example would be an A/D Converter >> class - My little control box might have 3 or 4 A/Ds in it - they're >> always there and I want the data associated with them to be static (not >> declared on the stack.) >> >> Question: What is the preferred Ada idiom for defining such a creature? See my previous post. You could either declare the known instances in the package itself: package AD_Converters is type AD_Converter (<>) is limited private; ... -- ops function Huey return AD_Converter; function Dewey return AD_Converter; function Louie return AD_Converter; end AD_Converters; The other possibility is to declare each function as a child: package AD_Converters.Huey_Converters is function Huey return AD_Converter; end; Alternatively, you can hide the package like this: function AD_Converters.Huey return AD_Converter; --spec private package AD_Converters.Huey_Converters is Huey : AD_Converter; .. --whatever else is necessary for the Huey object end; with AD_Converters.Huey_Conveters; function AD_Converters.Huey return AD_Converter is --body begin return Huey_Converters.Huey; end; Whether you declare all the objects up in the root package or as child functions is determined by whether your application always manipulates the objects as a group (that's the case in the genealogy example), and how many unique dependencies each object has (if the library units you need to make a Huey object are the same as the library units you need to make a Dewey object, then they might as well be declared together). ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-18 12:14 ` Martin Krischik 2004-10-18 19:40 ` Matthew Heaney @ 2004-10-19 12:59 ` Marin David Condic 2004-10-19 14:46 ` Martin Dowie 2004-10-19 15:52 ` Matthew Heaney 1 sibling, 2 replies; 55+ messages in thread From: Marin David Condic @ 2004-10-19 12:59 UTC (permalink / raw) So you would do something that looked like this: package AD_Converter_Class_And_Objects is type AD_Converter is tagged private ; procedure Some_Op (AD : in out AD_Converter) ; AD_Number_1 : AD_Converter ; private --stuff end AD_Converter_Class_And_Objects ; Similarly if I had a half-dozen of these puppies? If I had only one, you'd want to hide it in the package body and make the package be an object instead of a class? Would there be a reason to prefer making a child package to contain one or more objects of the class? Or a separate child package for each object? There could be plusses and minuses to any given approach. I'm mostly wondering what most Ada programmers prefer or tend to use. MDC Martin Krischik wrote: > Marin David Condic wrote: > > >>Suppose I have a class with one or a limited set of objects. The objects >>are "global" in the sense that they hang around from program startup >>thru the entire life of execution. An example would be an A/D Converter >>class - My little control box might have 3 or 4 A/Ds in it - they're >>always there and I want the data associated with them to be static (not >>declared on the stack.) >> >>Question: What is the preferred Ada idiom for defining such a creature? >> >>I have a package that defines the class - that contains the tagged type >>and any methods. I might: >> >>a) Declare the objects within that "class" package > > > Yes, within the class body only. > > >>b) Declare the objects within some child package of the class package > > > If there are a lot of static data, use a private package. > > For both: When multi tasking is an issue use a protected type to secure > access to the data. > > >>c) Declare the objects in some global "Here's all my static data" >>package (not very tidy) > > > No. > > >>d) Declare the objects in the main program (not good if they are >>accessed by more than one task and also a kind of dumping ground) > > > No as well. Each package has it > > >>Does anybody have an opinion or experience with doing this? I know what >>I've done in the past, but I'm curious if there is any preferred method >>or idiom for this in the OO paradigm as applied to Ada? > > > If you truly thing about OO you would us a singelton class. You know a class > where only one instance exists. Within the singelton class (package body) > you can either use class data or static data. It would not matter since is > is all hidden inside the package body. > > With Regards > > Martin > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Power corrupts. Absolute power is kind of neat" -- John Lehman, Secretary of the Navy 1981-1987 ====================================================================== ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-19 12:59 ` Marin David Condic @ 2004-10-19 14:46 ` Martin Dowie 2004-10-19 15:55 ` Matthew Heaney 2004-10-19 15:52 ` Matthew Heaney 1 sibling, 1 reply; 55+ messages in thread From: Martin Dowie @ 2004-10-19 14:46 UTC (permalink / raw) Marin David Condic wrote: > There could be plusses and minuses to any given approach. I'm mostly > wondering what most Ada programmers prefer or tend to use. Personally, I would _never_ mix classes (or ADT's) and instances of them within the same package or even in the same package hierarchy. Neither would I never make data items public. It does lead to some extra lines of code but in my experience it makes testing easier and maintenance _much_ easier. -- Martin ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-19 14:46 ` Martin Dowie @ 2004-10-19 15:55 ` Matthew Heaney 2004-10-19 18:31 ` Martin Dowie 0 siblings, 1 reply; 55+ messages in thread From: Matthew Heaney @ 2004-10-19 15:55 UTC (permalink / raw) "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message news:cl39c4$k1j$1@hercules.btinternet.com... > > Personally, I would _never_ mix classes (or ADT's) and instances of them > within the same package or even in the same package hierarchy. I suggest you start using Ada95 to program in ... Ada95. Declare the type as limited and indefinite, and declare selector functions to return references to the statically-declared instances. Just like Text_IO. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-19 15:55 ` Matthew Heaney @ 2004-10-19 18:31 ` Martin Dowie 0 siblings, 0 replies; 55+ messages in thread From: Martin Dowie @ 2004-10-19 18:31 UTC (permalink / raw) Matthew Heaney wrote: > "Martin Dowie" <martin.dowie@btopenworld.com> wrote in message > news:cl39c4$k1j$1@hercules.btinternet.com... >> >> Personally, I would _never_ mix classes (or ADT's) and instances of >> them within the same package or even in the same package hierarchy. > > I suggest you start using Ada95 to program in ... Ada95. Thanks for the suggestion but I'll pass for now... ;-) It is a style that was developed pre-95 but it works, has proven itself to produce very re-usable code (which embedding 'project specific' instances into potentially multi-project class/ADT's won't). If the ADT/class was indeed total specific to a project and there were always only going to be instances X, Y and Z, then fair we might look at a different style. But most of the ADT/classes we write just don't fall into that category. It's a style that also works for our 'C' projects (and Ada83 too, of course) and it works with all the CASE tools we use too (Teamwork, Real-time Studio). There are too many other "process and procedure fish to fry than changing this (all non-Ada related). -- Martin ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-19 12:59 ` Marin David Condic 2004-10-19 14:46 ` Martin Dowie @ 2004-10-19 15:52 ` Matthew Heaney 1 sibling, 0 replies; 55+ messages in thread From: Matthew Heaney @ 2004-10-19 15:52 UTC (permalink / raw) "Marin David Condic" <nobody@noplace.com> wrote in message news:Oc8dd.2347$ta5.1598@newsread3.news.atl.earthlink.net... > So you would do something that looked like this: > > package AD_Converter_Class_And_Objects is > > type AD_Converter is tagged private ; > > procedure Some_Op (AD : in out AD_Converter) ; > > AD_Number_1 : AD_Converter ; > > private > --stuff > end AD_Converter_Class_And_Objects ; Well, obviously this won't work, since you can't declare object AD_Number_1 prior to declaration of the full view of private type AD_Converter. And why did you name the package "...Class_And_Objects". Don't you mean "...Type_And_Objects"? This is very, very confusing! > Similarly if I had a half-dozen of these puppies? If I had only one, you'd > want to hide it in the package body and make the package be an object > instead of a class? What do you mean "instead of a class"? Do you mean "type" or "class"? If you mean "type", then why don't you say that? > Would there be a reason to prefer making a child package to contain one or > more objects of the class? Or a separate child package for each object? Do you mean one or more "objects of the type"? Why are you saying "class" here? This is very, very confusing! > There could be plusses and minuses to any given approach. I'm mostly > wondering what most Ada programmers prefer or tend to use. I showed you how to do this in another post. Declare the type as limited an indefinite, and provide functions that return a references to the statically-declared objects. Just like Text_IO. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-18 11:47 Idiom for a class and an object in Ada Marin David Condic 2004-10-18 12:14 ` Martin Krischik @ 2004-10-18 12:26 ` Marius Amado Alves 2004-10-19 2:09 ` Jeffrey Carter 2004-10-19 12:38 ` Marin David Condic 2004-10-18 16:59 ` Matthew Heaney ` (2 subsequent siblings) 4 siblings, 2 replies; 55+ messages in thread From: Marius Amado Alves @ 2004-10-18 12:26 UTC (permalink / raw) To: comp.lang.ada > Suppose I have a class with one or a limited set of objects. The objects > are "global" in the sense that they hang around from program startup > thru the entire life of execution. An example would be an A/D Converter > class - My little control box might have 3 or 4 A/Ds in it - they're > always there and I want the data associated with them to be static (not > declared on the stack.) > > Question: What is the preferred Ada idiom for defining such a creature? generic Line : Number; package AD_Converter is function OK return Boolean; function Get return Value; end; package Heat is new AD_Converter (123); package Noise is new AD_Converter (456); package Wind is new AD_Converter (789); -- You can't get more "static" than that! ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-18 12:26 ` Marius Amado Alves @ 2004-10-19 2:09 ` Jeffrey Carter 2004-10-19 3:28 ` Matthew Heaney 2004-10-19 12:38 ` Marin David Condic 1 sibling, 1 reply; 55+ messages in thread From: Jeffrey Carter @ 2004-10-19 2:09 UTC (permalink / raw) Marius Amado Alves wrote: > generic > Line : Number; > package AD_Converter is > function OK return Boolean; > function Get return Value; > end; > > package Heat is new AD_Converter (123); > package Noise is new AD_Converter (456); > package Wind is new AD_Converter (789); > > -- You can't get more "static" than that! Or simple. Or Ada-like. The other suggestions look too much like C++ for my taste. -- Jeff Carter "Apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, the fresh water system, and public health, what have the Romans ever done for us?" Monty Python's Life of Brian 80 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-19 2:09 ` Jeffrey Carter @ 2004-10-19 3:28 ` Matthew Heaney 2004-10-19 12:53 ` Marin David Condic 2004-10-20 1:10 ` Jeffrey Carter 0 siblings, 2 replies; 55+ messages in thread From: Matthew Heaney @ 2004-10-19 3:28 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> writes: > Marius Amado Alves wrote: > > > generic > > Line : Number; > > package AD_Converter is > > function OK return Boolean; > > function Get return Value; > > end; > > package Heat is new AD_Converter (123); > > package Noise is new AD_Converter (456); > > package Wind is new AD_Converter (789); > > -- You can't get more "static" than that! > > Or simple. Or Ada-like. The other suggestions look too much like C++ > for my taste. Too much code bloat. There's no reason AD_Converter needs to be a generic, if the objects of that type are known apriori: package AD_Converters is pragma Elaborate_Body; type AD_Converter (<>) is limited private; function OK (Converter : AD_Converter) return Boolean; function Get (Converter : AD_Converter) return Value; function Heat return AD_Converter; function Noise return AD_Converter; function Wind return AD_Converter; private type AD_Converter (Line : Number) is limited record ...; end AD_Converters; package body AD_Converters is ... Heat_ADC : AD_Conveter (123); Noise_ADC : AD_Converter (456); Wind_ADC : AD_Converter (789); function Heat return AD_Converter is begin return Heat_ADC; end; function Noise return AD_Converter is begin return Noise_ADC; end; function Wind return AD_Converter is begin return Wind_ADC; end; end AD_Converters; Alternatively, you could declare the objects each in their own private package: function AD_Converters.Heat return AD_Converter; private package AD_Converters.Heat_AD_Converters is Heat_AD_Converter : AD_Converter (123); ... -- whatever else end; with AD_Converters.Heat_AD_Converters; function AD_Converters.Heat return AD_Converter is begin return AD_Converters.Heat_AD_Converter; end; This would be useful if each AD_Converter object had distinct library dependencies. (Although it might not matter that much anyway, since such dependencies would have been limited to the body.) ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-19 3:28 ` Matthew Heaney @ 2004-10-19 12:53 ` Marin David Condic 2004-10-19 14:44 ` Matthew Heaney 2004-10-20 5:39 ` Simon Wright 2004-10-20 1:10 ` Jeffrey Carter 1 sibling, 2 replies; 55+ messages in thread From: Marin David Condic @ 2004-10-19 12:53 UTC (permalink / raw) Actually, the A/D converter might be used to read a whole variety of values. You multiplex the inputs. Maybe my question isn't really clear. I'm thinking of something of the flavor: package AD_Converter_Class is type AD_Converter is tagged private ; procedure Some_Op_Like_Read_The_AD_Converter ( Converter : in out AD_Converter) ; end AD_Converter_Class ; Don't get hung up on it being an AD converter. The question relates more to the proper idiom for a class that might have one or a few static objects (as opposed to anything I might dynamically create and destroy through the life of a program) Where would the best place be to declare the objects of that class assuming that the storage must be static? You could do this: package AD_Converter_Class.AD_Number_One is AD : AD_Converter ; end AD_Converter_Class.AD_Number_One ; Or you could do something like: with AD_Converter_Class ; package All_My_Global_Junk is AD1 : AD_Converter_Class.AD_Converter ; AD2 : AD_Converter_Class.AD_Converter ; end All_My_Global_Junk ; Or you could do something like: with AD_Converter_Class ; procedure The_Main_Program is AD1 : AD_Converter_Class.AD_Converter ; AD2 : AD_Converter_Class.AD_Converter ; begin stuff ; end The_Main_Program ; Or you could declare them in some package that used them - but that might be lots of possible packages. The main program option has weaknesses in that the objects may need to be visible across a variety of tasks. I generally don't like a "dumping ground" package that declares all the global storage - maybe if it might be limited to just objects of the one class it might seem more palatable. That's not too different than creating a child package for the objects. One child package for all objects? One child package per object? What is the preferred Ada idiom for something like this? MDC Matthew Heaney wrote: > Jeffrey Carter <spam@spam.com> writes: > > >>Marius Amado Alves wrote: >> >> >>>generic >>> Line : Number; >>>package AD_Converter is >>> function OK return Boolean; >>> function Get return Value; >>>end; >>>package Heat is new AD_Converter (123); >>>package Noise is new AD_Converter (456); >>>package Wind is new AD_Converter (789); >>>-- You can't get more "static" than that! >> >>Or simple. Or Ada-like. The other suggestions look too much like C++ >>for my taste. > > > > Too much code bloat. There's no reason AD_Converter needs to be a > generic, if the objects of that type are known apriori: > > package AD_Converters is > pragma Elaborate_Body; > > type AD_Converter (<>) is limited private; > > function OK (Converter : AD_Converter) return Boolean; > function Get (Converter : AD_Converter) return Value; > > function Heat return AD_Converter; > function Noise return AD_Converter; > function Wind return AD_Converter; > > private > > type AD_Converter (Line : Number) is limited record ...; > > end AD_Converters; > > > package body AD_Converters is > ... > > Heat_ADC : AD_Conveter (123); > Noise_ADC : AD_Converter (456); > Wind_ADC : AD_Converter (789); > > function Heat return AD_Converter is > begin > return Heat_ADC; > end; > > function Noise return AD_Converter is > begin > return Noise_ADC; > end; > > function Wind return AD_Converter is > begin > return Wind_ADC; > end; > > end AD_Converters; > > > Alternatively, you could declare the objects each in their own private package: > > function AD_Converters.Heat return AD_Converter; > > private package AD_Converters.Heat_AD_Converters is > Heat_AD_Converter : AD_Converter (123); > ... -- whatever else > end; > > with AD_Converters.Heat_AD_Converters; > function AD_Converters.Heat return AD_Converter is > begin > return AD_Converters.Heat_AD_Converter; > end; > > > This would be useful if each AD_Converter object had distinct library > dependencies. (Although it might not matter that much anyway, since > such dependencies would have been limited to the body.) -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Power corrupts. Absolute power is kind of neat" -- John Lehman, Secretary of the Navy 1981-1987 ====================================================================== ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-19 12:53 ` Marin David Condic @ 2004-10-19 14:44 ` Matthew Heaney 2004-10-19 15:01 ` Dmitry A. Kazakov 2004-10-20 5:39 ` Simon Wright 1 sibling, 1 reply; 55+ messages in thread From: Matthew Heaney @ 2004-10-19 14:44 UTC (permalink / raw) "Marin David Condic" <nobody@noplace.com> wrote in message news:s78dd.2345$ta5.833@newsread3.news.atl.earthlink.net... > > Maybe my question isn't really clear. I'm thinking of something of the > flavor: > > package AD_Converter_Class is > > type AD_Converter is tagged private ; > > procedure Some_Op_Like_Read_The_AD_Converter ( > Converter : in out AD_Converter) ; > > end AD_Converter_Class ; > > Don't get hung up on it being an AD converter. The question relates more > to the proper idiom for a class that might have one or a few static > objects (as opposed to anything I might dynamically create and destroy > through the life of a program) Where would the best place be to declare > the objects of that class assuming that the storage must be static? First of all, if we're going to have a conversation, we need to agree on terms. The term "class" in Ada has a very specific meaning. In Ada, it means "family of types." Specifically, it means "family of tagged types, having this common ancestor." You said above "proper idiom for a class," but it's not clear whether you just mean "type," or whether you mean "class" (as in "family of types"). If you just mean "type," then say so. It certainly doesn't help anyone that you named the package AD_Converter_Class. In fact it's horribly confusing. Please use Ada terms, or I won't understand you. Don't say "class" if you mean "type." Secondly, you haven't explained why your AD_Converter type is tagged, or why it's non-limited. (What does assignment of AD_Converter objects even mean???) Please give me a reason why this type is tagged, and if it's tagged then please tell me about its descendents. > What is the preferred Ada idiom for something like this? I showed you the proper idiom. What's the problem? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-19 14:44 ` Matthew Heaney @ 2004-10-19 15:01 ` Dmitry A. Kazakov 2004-10-19 15:40 ` Matthew Heaney 0 siblings, 1 reply; 55+ messages in thread From: Dmitry A. Kazakov @ 2004-10-19 15:01 UTC (permalink / raw) On Tue, 19 Oct 2004 10:44:04 -0400, Matthew Heaney wrote: > The term "class" in Ada has a very specific meaning. In Ada, it means > "family of types." Specifically, it means "family of tagged types, having > this common ancestor." This is incorrect. For example ARM 12.5 refers classes of types other than "class rooted in". -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-19 15:01 ` Dmitry A. Kazakov @ 2004-10-19 15:40 ` Matthew Heaney 2004-10-20 7:58 ` Dmitry A. Kazakov 0 siblings, 1 reply; 55+ messages in thread From: Matthew Heaney @ 2004-10-19 15:40 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:138j4nfhzsc45$.1581kzqfi5e89$.dlg@40tude.net... > On Tue, 19 Oct 2004 10:44:04 -0400, Matthew Heaney wrote: > >> The term "class" in Ada has a very specific meaning. In Ada, it means >> "family of types." Specifically, it means "family of tagged types, >> having >> this common ancestor." > > This is incorrect. For example ARM 12.5 refers classes of types other than > "class rooted in". Yes, of course it does, but that's obviously not what we're discussing here, since the OP isn't using the term "class" in the sense of "class of integer types," etc. We simply need to clarify whether we're talking about a specific type T, or a family of types rooted at T, namely T'Class. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-19 15:40 ` Matthew Heaney @ 2004-10-20 7:58 ` Dmitry A. Kazakov 2004-10-20 12:31 ` Marin David Condic 0 siblings, 1 reply; 55+ messages in thread From: Dmitry A. Kazakov @ 2004-10-20 7:58 UTC (permalink / raw) On Tue, 19 Oct 2004 11:40:08 -0400, Matthew Heaney wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:138j4nfhzsc45$.1581kzqfi5e89$.dlg@40tude.net... >> On Tue, 19 Oct 2004 10:44:04 -0400, Matthew Heaney wrote: >> >>> The term "class" in Ada has a very specific meaning. In Ada, it means >>> "family of types." Specifically, it means "family of tagged types, >>> having >>> this common ancestor." >> >> This is incorrect. For example ARM 12.5 refers classes of types other than >> "class rooted in". > > Yes, of course it does, but that's obviously not what we're discussing here, > since the OP isn't using the term "class" in the sense of "class of integer > types," etc. > > We simply need to clarify whether we're talking about a specific type T, or > a family of types rooted at T, namely T'Class. [ BTW, to be even more pedantic (:-)), T'Class is not a family of types. It is *a* type, which is a closure of that family. ] Anyway, I see nothing criminal in the package name "AD_Converter_Class". The names should reflect the application domain, rather than language gears. With some minor exceptions, which IMO always more or less reflect language deficiencies (I mean XXX_Ptr, XXX_Type etc), Hungarian notation and company is an evil thing. I have no problem to read AD_Converter_Class as "a class of physical devices, described in general by this package". Whether that class is mapped to a type or to a class of related types is a design decision. But the original question was how to name the ultimate instances of that type or types of a family, including generic case, sets of derived types, constrained subtypes, whatsoever. The idiom should not depend on where the instances come from. So important is only (if I correctly understood Marin): 1. Instances are statically known 2. Instances should be public 3. Instances should have unique names (no arrays of, no containers of, no factories of) My personal preference is (b) - child packages. When necessary, one can additionally create an assembly package with renames of converters instances from different packages: with AD_Converter_Class.Diamond; with AD_Converter_Class.AX10410A; ... package AD_Converter_Class.This_Board_Hardware is AD_1 : AD_Converter_Class.Diamond_MM.AD; AD_2 : AD_Converter_Class.AX10410A.AD; ... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 7:58 ` Dmitry A. Kazakov @ 2004-10-20 12:31 ` Marin David Condic 2004-10-20 13:53 ` Dmitry A. Kazakov 2004-10-20 15:23 ` Matthew Heaney 0 siblings, 2 replies; 55+ messages in thread From: Marin David Condic @ 2004-10-20 12:31 UTC (permalink / raw) Dmitry A. Kazakov wrote: > Anyway, I see nothing criminal in the package name "AD_Converter_Class". > The names should reflect the application domain, rather than language > gears. With some minor exceptions, which IMO always more or less reflect > language deficiencies (I mean XXX_Ptr, XXX_Type etc), Hungarian notation > and company is an evil thing. I have no problem to read AD_Converter_Class > as "a class of physical devices, described in general by this package". > Whether that class is mapped to a type or to a class of related types is a > design decision. > I didn't want to get hung up on names or the chosen example of A/D converters or any of that, so folks should just substitute whatever names they consider in good taste. I paint with a broad brush most of the time. Consider it this way: You go to an Object Oriented Design class and Grady Booch starts explaining to you about a "Class" with "Attributes" and "Methods". Having learned all that, you basically discover that the corresponding Ada idiom for a class would be a package with a tagged type and a bunch of functions & procedures to act as the methods. (Am I wrong about that? Is there some other preferred idiom for implementing a 'class' in Ada?) So now you want to say "I have this 'class' called a Blivet and I might want to have a "Blue_Blivet" and a "Shiny_Blue_Blivet" and a "Big_Shiny_Blue_Blivet" so the natural thing to do is make a 'class' from a package and a tagged type and a bunch of subprograms. Having done that, you find you have a constraint: For reasons having nothing special to do with Ada, you want all the data for the 'objects' of that class to be in static storage and not involve access types and all that. No generics because of code bloat and other issues. Any other issues such as private vs limited private are all just sidebars having nothing special to do with the question at hand. You can get what I describe with a simple declaraion of "My_Blivet : Blivet;" put somewhere at the Library level. To repeat my question: What is the preferred Ada idiom (when talking about Object Oriented methodology) for declaring those objects? > > My personal preference is (b) - child packages. When necessary, one can > additionally create an assembly package with renames of converters > instances from different packages: > > with AD_Converter_Class.Diamond; > with AD_Converter_Class.AX10410A; > ... > package AD_Converter_Class.This_Board_Hardware is > AD_1 : AD_Converter_Class.Diamond_MM.AD; > AD_2 : AD_Converter_Class.AX10410A.AD; > ... > And there we get an answer to at least one preferred method of doing this. I have used this idiom myself in the past. I've noticed that GtkAda seems to use an idiom wherein they declare all the stuff relating to a window in a package spec, followed by an access type declaration that then exercises an allocator to create the single object of that window. It works and I have no grief with it, except that in the particular case of interest, I don't want to use an allocator. Is there a consensus that this ought to be the idiom of choice when you *don't* care about the allocator? MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Power corrupts. Absolute power is kind of neat" -- John Lehman, Secretary of the Navy 1981-1987 ====================================================================== ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 12:31 ` Marin David Condic @ 2004-10-20 13:53 ` Dmitry A. Kazakov 2004-10-20 15:23 ` Matthew Heaney 1 sibling, 0 replies; 55+ messages in thread From: Dmitry A. Kazakov @ 2004-10-20 13:53 UTC (permalink / raw) On Wed, 20 Oct 2004 12:31:48 GMT, Marin David Condic wrote: > Consider it this way: You go to an Object Oriented Design class and > Grady Booch starts explaining to you about a "Class" with "Attributes" > and "Methods". Having learned all that, you basically discover that the > corresponding Ada idiom for a class would be a package with a tagged > type and a bunch of functions & procedures to act as the methods. (Am I > wrong about that? Is there some other preferred idiom for implementing a > 'class' in Ada?) Maybe I am preaching heresy, but I find Ada's type/operation/package view more usable than class/attribute/method. So I don't much care what would be an OO-ish class in Ada. (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 12:31 ` Marin David Condic 2004-10-20 13:53 ` Dmitry A. Kazakov @ 2004-10-20 15:23 ` Matthew Heaney 2004-10-21 12:24 ` Marin David Condic 1 sibling, 1 reply; 55+ messages in thread From: Matthew Heaney @ 2004-10-20 15:23 UTC (permalink / raw) "Marin David Condic" <nobody@noplace.com> wrote in message news:UUsdd.3499$ta5.1160@newsread3.news.atl.earthlink.net... > > So now you want to say "I have this 'class' called a Blivet and I might > want to have a "Blue_Blivet" and a "Shiny_Blue_Blivet" and a > "Big_Shiny_Blue_Blivet" so the natural thing to do is make a 'class' from > a package and a tagged type and a bunch of subprograms. You still haven't explained why TYPE Blivet is tagged and nonlimited. > Having done that, you find you have a constraint: For reasons having > nothing special to do with Ada, you want all the data for the 'objects' of > that class to be in static storage and not involve access types and all > that. No generics because of code bloat and other issues. Any other issues > such as private vs limited private are all just sidebars having nothing > special to do with the question at hand. You can get what I describe with > a simple declaraion of "My_Blivet : Blivet;" put somewhere at the Library > level. To repeat my question: > > What is the preferred Ada idiom (when talking about Object Oriented > methodology) for declaring those objects? To repeat my answer: declare the TYPE as limited and indefinite, and declare selector functions that return references to the statically declared instances. Just like Text_IO. Limited types are passed by reference, so one way to do sans access types is like this: package Blivets is type Blivet (<>) is limited private; procedure Op (B : Blivet); function My_Blivet return Blivet; private type Blivet is limited record .. end record; end; package body Blivets is ... My_Blivet_Object : Blivet; function My_Blivet return Blivet is begin return My_Blivet_Object; end; end Blivets; Limited types are passed by reference, so neither allocation nor access types are necessary. Note that using access types doesn't imply allocation, so it's not clear to me what you have against access types. Another possibility is to implement the type as an access type (so direct pointer manipulation isn't necessary): package Blivets is type Blivet (<>) is limited private; procedure Op (B : Blivet); function My_Blivet return Blivet; private type Rep_Type is <whatever>; type Blivet is access all Rep_Type; for Blivet'Storage_Size use 0; end Blivets; package body Blivets is ... My_Blivet_Object : aliased Rep_Type; function My_Blivet return Blivet is begin return My_Blivet_Object'Access; end; end Blivets; This has the benefit that objects are allocated statically, and all uses of pointers are hidden from the user. Yet another possibility is to expose the access type, but pass the object as an access parameter: package Blivets is type Blivet (<>) is limited private; procedure Op (B : access Blivet); type Blivet_Access is access all Blivet; for Blivet_Access'Storage_Size use 0; My_Blivet : constant Blivet_Access; private type Blivet is limited record ... end record; My_Blivet_Object : aliased Blivet; My_Blivet : constant Blivet_Access := My_Blivet_Object'Access; end Blivets; So take your pick! In all cases, the objects are declared statically, which satisfies your primary constraint. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 15:23 ` Matthew Heaney @ 2004-10-21 12:24 ` Marin David Condic 2004-10-21 17:15 ` Matthew Heaney 0 siblings, 1 reply; 55+ messages in thread From: Marin David Condic @ 2004-10-21 12:24 UTC (permalink / raw) Matthew Heaney wrote: > > You still haven't explained why TYPE Blivet is tagged and nonlimited. > > I would have a)thought that was clear and b) mostly irrelavent to my question. Since one *can* use a tagged type (natural for extension, etc.) then what does one do when declaring objects of that type? Limited or not, you still have to declare them somewhere. Why tagged? Why not? Its a language feature and I'm curious about what is the preferred idiom for doing so. Or is it your view that tagged types should never be used? > > > To repeat my answer: declare the TYPE as limited and indefinite, and > declare selector functions that return references to the statically > declared instances. Just like Text_IO. > And just as extensible. How do I get my Big_Shiny_Blue_Blivet from the limited, indefinite declaration? > Limited types are passed by reference, so one way to do sans access > types is like this: > > package Blivets is type Blivet (<>) is limited private; > > procedure Op (B : Blivet); > > function My_Blivet return Blivet; private type Blivet is limited > record .. end record; end; > > package body Blivets is ... My_Blivet_Object : Blivet; > > function My_Blivet return Blivet is begin return My_Blivet_Object; > end; end Blivets; > > Limited types are passed by reference, so neither allocation nor > access types are necessary. > So if I may interpolate, your preference would be to put the object declaration in the package body of the package that creates the class? > Note that using access types doesn't imply allocation, so it's not > clear to me what you have against access types. Another possibility > is to implement the type as an access type (so direct pointer > manipulation isn't necessary): > Let's just say "Because I don't feel like it." It would give me problems with things having nothing to do with Ada and I don't see any need to do so since a declaration of "Object : Class ;" is totally sufficient for the job. Keep in mind, I'm not asking about a dozen different style issues - I'm asking about the preferred scope for a fixed set of static "objects" (in the OO sense) when one is following the OO methodology. With or without access types and with or without functions returning the object, the object has an existence within some scope. It seems to me that the choices are: Somewhere within the package spec that defines the "Class" Somewhere within the package body that defines the "Class" In a child package of the parent defining the "Class" In several child packages (one for each object) of the parent defining the "Class" In some unrelated library level package wherein presumably one might at least group together related declarations. The main program Even if you do it with some limited and indefinite type because you have some dislike of tagged types, you still have to declare it somewhere. An access object only provides a level of indirection so the access object could be in the package spec, the body, one or more child packages or a completely unrelated library level package or the main program. > > So take your pick! In all cases, the objects are declared > statically, which satisfies your primary constraint. > > Well, I can and do take my pick on a regular basis. The question on my mind was "Is there a generally accepted Ada idiom when implementing the OO Design of some class with a limited set of static objects?" You've shown one method - albeit, one that avoids the customary tagged records designed into Ada to support OO programming. (Given the texts I've looked over on OO programming in Ada - they tend to lean towards that idiom rather than other possible techniques.) The question in my mind from the OO Design in Ada texts has been because the texts usually discuss all the issues of developing classes, but in their limited examples, they usually declare the objects within the scope of the main program. Presumably, a whole system would eventually be rolled up into one big class with one big object declared at the main program level. Since this is not always the case nor is it always desirable, my question was about the right idiom to employ when I *don't* have the objects all defined in the main program or on the fly in dynamic situations. I hope this clarifies what I was looking for. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Power corrupts. Absolute power is kind of neat" -- John Lehman, Secretary of the Navy 1981-1987 ====================================================================== ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-21 12:24 ` Marin David Condic @ 2004-10-21 17:15 ` Matthew Heaney 0 siblings, 0 replies; 55+ messages in thread From: Matthew Heaney @ 2004-10-21 17:15 UTC (permalink / raw) "Marin David Condic" <nobody@noplace.com> wrote in message news:jUNdd.3252$5i5.107@newsread2.news.atl.earthlink.net... > Matthew Heaney wrote: >> >> You still haven't explained why TYPE Blivet is tagged and nonlimited. >> >> > I would have a)thought that was clear and b) mostly irrelavent to my > question. Since one *can* use a tagged type (natural for extension, > etc.) then what does one do when declaring objects of that type? > Limited or not, you still have to declare them somewhere. Why tagged? > Why not? That's the wrong question. The question should be, Why? Do you need type extension? Do you need polymorphism (dynamic binding)? If no, then clear you don't need a tagged type. > Its a language feature and I'm curious about what is the > preferred idiom for doing so. Or is it your view that tagged types > should never be used? I'm saying they should be used when you need type extension and dynamic binding. Otherwise you can use a non-tagged type. >> To repeat my answer: declare the TYPE as limited and indefinite, and >> declare selector functions that return references to the statically >> declared instances. Just like Text_IO. >> > And just as extensible. How do I get my Big_Shiny_Blue_Blivet from the > limited, indefinite declaration? If you need type extension, then clearly you need a tagged type. But that is orthogonal to the issue of limitedness and indefiniteness: package Blivets is type Blivet (<>) is tagged limited private; ... end; package Blivets.Big_Shiny_Blue is type Big_Shiny_Blue_Blivet (<>) is new Blivet with private; ... end; > So if I may interpolate, your preference would be to put the object > declaration in the package body of the package that creates the class? Yes. Or the objects could be a declared child package. As I showed in another post, you can even make the child package private, and make the selector function a public child. >> Note that using access types doesn't imply allocation, so it's not >> clear to me what you have against access types. Another possibility >> is to implement the type as an access type (so direct pointer >> manipulation isn't necessary): >> > Let's just say "Because I don't feel like it." It would give me problems > with things having nothing to do with Ada and I don't see any need to do > so since a declaration of "Object : Class ;" is totally sufficient for > the job. Keep in mind, I'm not asking about a dozen different style > issues - I'm asking about the preferred scope for a fixed set of static > "objects" (in the OO sense) when one is following the OO methodology. I don't know what an object is "in the OO sense" or what "OO methodology" is (I just call it "programming"), but if these are a fixed set of well-known objects, then I would declare the type as limited and indefinite (or tagged, if necessary), and declare the instances either in the package itself, or in (possibly private) child packages. > Even if you do it with some limited and indefinite type because you have > some dislike of tagged types, No, I have no dislike of tagged types. I have a dislike of using tagged types where a non-tagged type will do. I have a dislike of using non-limited types when a limited type will do. The issue of taggedness is orthogonal to the issue of limitedness is orthogonal to the issue of indefiniteness. See my example above. -Matt ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-19 12:53 ` Marin David Condic 2004-10-19 14:44 ` Matthew Heaney @ 2004-10-20 5:39 ` Simon Wright 2004-10-20 7:24 ` Matthew Heaney 2004-10-20 17:04 ` Matthew Heaney 1 sibling, 2 replies; 55+ messages in thread From: Simon Wright @ 2004-10-20 5:39 UTC (permalink / raw) Marin David Condic <nobody@noplace.com> writes: > What is the preferred Ada idiom for something like this? I'm not so hung up as Matt about people using the word class (in conversation; I agree about use in Ada code). But I have to say, what's wrong with Matt's suggestion? seems to answer all your needs as stated so far .. One thing, having "static" (I suppose you mean, created at library level during elaboration, whatever the words are ..) can cause elaboration order problems if the things being created are tasks. I could say that more strongly, "are practically guaranteed to cause elaboration order problems"! I guess this is unlikely to happen with hardware interfaces?? Not sure if using dynamic allocation in elaboration would help? -- probably not, need some sort of Initialize procedure. package body ADC is task type T is ... type T_P is access T; Converter_1 : T_P; begin Converter_1 := new T (...); end ADC; ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 5:39 ` Simon Wright @ 2004-10-20 7:24 ` Matthew Heaney 2004-10-20 8:39 ` Dmitry A. Kazakov ` (2 more replies) 2004-10-20 17:04 ` Matthew Heaney 1 sibling, 3 replies; 55+ messages in thread From: Matthew Heaney @ 2004-10-20 7:24 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > I'm not so hung up as Matt about people using the word class (in > conversation; I agree about use in Ada code). But I have to say, > what's wrong with Matt's suggestion? seems to answer all your needs as > stated so far .. For reasons I can't fathom, many Ada95 developers still have a very Ada83 mindset. This is the canonical idiom in C++ for controlling instance creation: class C { public: static C* make( /* ... */ ); static void free(C*); void f(); //whatever private: C(); C(const C&); ~C(); C& operator=(const C&); }; Here, the ctor (and dtor) is declared as private, so the only way to make a C object is by calling factory function C::make(). This has a direct translation into Ada95: package P is type T (<>) is limited private; procedure Op (O : in out T); type T_Access is access all T; function New_T (...) return T_Access; private type T is limited record ...; end P; Here the package provides a factory function to dynamically create instances (or possibly return a pointer to statically declared objects, a la the Flyweight Pattern). Functions in Ada95 return constant objects. (In Ada83, functions returned values.) Types whose full view is limited are passed by reference. These two facts mean you can write the equivalent of a const reference in C++: const C& f(); by using a function whose return type is limited: package P is type T (<>) is limited private; procedure Op (O : in T); function Object1 return T; function Object2 return T; private type T is limited record ...; end P; This is exactly how Text_IO works. The objects returned by functions Standard_Input, Standard_Output, etc, correspond to the functions Object1 and Object2 above. This is the canonical Ada95 idiom for controlling instance creation, and for declaring well-known objects. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 7:24 ` Matthew Heaney @ 2004-10-20 8:39 ` Dmitry A. Kazakov 2004-10-21 1:36 ` Jeffrey Carter 2004-10-21 8:25 ` Martin Dowie 2 siblings, 0 replies; 55+ messages in thread From: Dmitry A. Kazakov @ 2004-10-20 8:39 UTC (permalink / raw) On Wed, 20 Oct 2004 07:24:31 GMT, Matthew Heaney wrote: > For reasons I can't fathom, many Ada95 developers still have a very > Ada83 mindset. Probably because Ada 83 was good! (:-)) > package P is > > type T (<>) is limited private; > > procedure Op (O : in T); > > function Object1 return T; > function Object2 return T; > > private > > type T is limited record ...; > > end P; This approach is difficult to follow with read-write objects, because it then forces to use indirection. > This is exactly how Text_IO works. The objects returned by functions > Standard_Input, Standard_Output, etc, correspond to the functions > Object1 and Object2 above. Yes and the price is heavy: procedure Put(File : in File_Type; Item : in Character); writes into *in* File! Even if File_Type is considered to be an "iterator", "access window" etc, rather than the file, then definitely Put and Get should *change* it. So what is File_Type? It is a language construct to provide a work-around for the pattern above, i.e. a hack. A bit watery for an IDIOM. > This is the canonical Ada95 idiom for controlling instance creation, and > for declaring well-known objects. Yes, but it lacks an ability to create non-constant objects on the stack, and it requires an extra indirection level. There should be a way for forward object declarations. type X (<>) is limited private; A : X renames private; -- Forward rename or so A : X := private; -- Forward initialization or A : private X; private type X is record Field : Integer; end record; A : X := (Field => 123); Then of course there should be a way for in-place modification of the result for by-reference types and copy-out/copy-in for all others. Anonymous access results are good, but I'd prefer a more elaborated solution without access types. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 7:24 ` Matthew Heaney 2004-10-20 8:39 ` Dmitry A. Kazakov @ 2004-10-21 1:36 ` Jeffrey Carter 2004-10-21 1:46 ` Matthew Heaney 2004-10-21 19:31 ` Kevin Cline 2004-10-21 8:25 ` Martin Dowie 2 siblings, 2 replies; 55+ messages in thread From: Jeffrey Carter @ 2004-10-21 1:36 UTC (permalink / raw) Matthew Heaney wrote: > For reasons I can't fathom, many Ada95 developers still have a very > Ada83 mindset. That's because Ada 83 was a very good language, and the idioms that were good for it are still good. > This is the canonical idiom in C++ for controlling instance creation: > > class C { > public: > > static C* make( /* ... */ ); > static void free(C*); > > void f(); //whatever > > private: > > C(); > C(const C&); > > ~C(); > > C& operator=(const C&); > }; > > Here, the ctor (and dtor) is declared as private, so the only way to > make a C object is by calling factory function C::make(). > > This has a direct translation into Ada95: > > package P is > > type T (<>) is limited private; > > procedure Op (O : in out T); > > type T_Access is access all T; > > function New_T (...) return T_Access; And this is why C++ is never a good guide to how to do things in Ada. The pointer may well be needed in C++; it's not needed in Ada. -- Jeff Carter "Ada has made you lazy and careless. You can write programs in C that are just as safe by the simple application of super-human diligence." E. Robert Tisdale 72 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-21 1:36 ` Jeffrey Carter @ 2004-10-21 1:46 ` Matthew Heaney 2004-10-21 7:51 ` Dmitry A. Kazakov 2004-10-22 1:04 ` Jeffrey Carter 2004-10-21 19:31 ` Kevin Cline 1 sibling, 2 replies; 55+ messages in thread From: Matthew Heaney @ 2004-10-21 1:46 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> writes: > Matthew Heaney wrote: > > > For reasons I can't fathom, many Ada95 developers still have a very > > Ada83 mindset. > > That's because Ada 83 was a very good language, and the idioms that were > good for it are still good. Ancient history. > And this is why C++ is never a good guide to how to do things in > Ada. The pointer may well be needed in C++; it's not needed in Ada. I don't understand this comment. How else do you dynamically create instances of T? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-21 1:46 ` Matthew Heaney @ 2004-10-21 7:51 ` Dmitry A. Kazakov 2004-10-21 12:45 ` Matthew Heaney 2004-10-22 1:04 ` Jeffrey Carter 1 sibling, 1 reply; 55+ messages in thread From: Dmitry A. Kazakov @ 2004-10-21 7:51 UTC (permalink / raw) On Thu, 21 Oct 2004 01:46:39 GMT, Matthew Heaney wrote: > Jeffrey Carter <spam@spam.com> writes: >> And this is why C++ is never a good guide to how to do things in >> Ada. The pointer may well be needed in C++; it's not needed in Ada. > > I don't understand this comment. How else do you dynamically create > instances of T? Why should they be created dynamically (heap)? Heap vs. stack is a matter of object's scope. It should have little or no impact on the design of the type. If it has then probably because of language deficiency, as in C++, or, yes, in Ada where there was no way to initialize limited objects. That will be corrected soon, I hope. For Marin's case the objects are not dynamic. So if read-only objects would suffice, one can just use functions returning limited objects: package Limited_Object is type X (<>) is limited private; function O1 return X; -- No pointer needed ... package body Limited_Object is O1_Value : X; function O1 return X is begin return O1_Value; -- This is OK, O1_Value is never out of scope end O1; ... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-21 7:51 ` Dmitry A. Kazakov @ 2004-10-21 12:45 ` Matthew Heaney 2004-10-21 14:11 ` Dmitry A. Kazakov 0 siblings, 1 reply; 55+ messages in thread From: Matthew Heaney @ 2004-10-21 12:45 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Thu, 21 Oct 2004 01:46:39 GMT, Matthew Heaney wrote: > > > I don't understand this comment. How else do you dynamically create > > instances of T? > > Why should they be created dynamically (heap)? Heap vs. stack is a > matter of object's scope. It should have little or no impact on the > design of the type. If it has then probably because of language > deficiency, as in C++, or, yes, in Ada where there was no way to > initialize limited objects. That will be corrected soon, I hope. My point was that there is *no* difference between Ada95 and C++ here. My reasons for writing the code as I did (that is, writing a factory function that returns a pointer) had nothing to do with language. > For Marin's case the objects are not dynamic. So if read-only objects > would suffice, one can just use functions returning limited objects: Finally, someone else sees the light... ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-21 12:45 ` Matthew Heaney @ 2004-10-21 14:11 ` Dmitry A. Kazakov 0 siblings, 0 replies; 55+ messages in thread From: Dmitry A. Kazakov @ 2004-10-21 14:11 UTC (permalink / raw) On Thu, 21 Oct 2004 12:45:09 GMT, Matthew Heaney wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On Thu, 21 Oct 2004 01:46:39 GMT, Matthew Heaney wrote: >> >>> I don't understand this comment. How else do you dynamically create >>> instances of T? >> >> Why should they be created dynamically (heap)? Heap vs. stack is a >> matter of object's scope. It should have little or no impact on the >> design of the type. If it has then probably because of language >> deficiency, as in C++, or, yes, in Ada where there was no way to >> initialize limited objects. That will be corrected soon, I hope. > > My point was that there is *no* difference between Ada95 and C++ here. > My reasons for writing the code as I did (that is, writing a factory > function that returns a pointer) had nothing to do with language. I see it different: 1. Why there should be a factory function? 2. Why that should return a pointer? The reasons for 1 could be: 1.a. There are construction parameters [not the case] 1.b. The result is polymorphic [not the case] 1.c. The language does not provide default object construction [not the case] 1.d. Renaming/aliasing, abstracting from variables [might be, but what's the gain?] The reasons for 2 could be: 2.a. The scope of the objects is dynamic and "new" does not fit [not the case] 2.b. The language has problems with construction on the stack. [might well be, if objects are limited] If we consider all that we will see that it is rather a language problem, that forces us to use pointers. >> For Marin's case the objects are not dynamic. So if read-only objects >> would suffice, one can just use functions returning limited objects: > > Finally, someone else sees the light... But if that is the case, then constants would do the trick. You need no function for that. Initialization is an independent issue. Function returning object is *not* a constructor, it could simulate one, but what for if the language supports construction? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-21 1:46 ` Matthew Heaney 2004-10-21 7:51 ` Dmitry A. Kazakov @ 2004-10-22 1:04 ` Jeffrey Carter 2004-10-22 1:36 ` Matthew Heaney 1 sibling, 1 reply; 55+ messages in thread From: Jeffrey Carter @ 2004-10-22 1:04 UTC (permalink / raw) Matthew Heaney wrote: > Jeffrey Carter <spam@spam.com> writes: > >>That's because Ada 83 was a very good language, and the idioms that were >>good for it are still good. > > Ancient history. What a meaningful reply. Obviously Heany has no valid refutation. > I don't understand this comment. How else do you dynamically create > instances of T? Ignoring the absence of any requirement that the objects be created dynamically, there are several ways: declare Instance : T renames Make (...); begin ... and procedure Process (Object : in out T); ... Process (Object => Make (...) ); -- Jeff Carter "Sons of a silly person." Monty Python & the Holy Grail 02 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-22 1:04 ` Jeffrey Carter @ 2004-10-22 1:36 ` Matthew Heaney 0 siblings, 0 replies; 55+ messages in thread From: Matthew Heaney @ 2004-10-22 1:36 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> writes: > Ignoring the absence of any requirement that the objects be created > dynamically, there are several ways: > > declare > Instance : T renames Make (...); > begin We appear to be comparing apples and oranges. The technique you show above will only work (assuming the full of the type is limited) if the object is allocated statically. You obviously cannot use a function to return an object whose type is limited (the full view, anyway), if the object is dynamically allocated on the stack. (Try it and see.) My example was only intended to illustrate the technique of using a factory function to allocate instances. The indirection allows the package to hide the decision about whether instances are allocated statically (e.g. the flyweight pattern) or dynamically. -Matt BTW: It's H-E-A-N-E-Y, like the poet. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-21 1:36 ` Jeffrey Carter 2004-10-21 1:46 ` Matthew Heaney @ 2004-10-21 19:31 ` Kevin Cline 2004-10-21 22:02 ` Matthew Heaney 1 sibling, 1 reply; 55+ messages in thread From: Kevin Cline @ 2004-10-21 19:31 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> wrote in message news:<woEdd.2702$%h1.1164@newsread3.news.pas.earthlink.net>... > Matthew Heaney wrote: > > > For reasons I can't fathom, many Ada95 developers still have a very > > Ada83 mindset. > > That's because Ada 83 was a very good language, and the idioms that were > good for it are still good. > > > This is the canonical idiom in C++ for controlling instance creation: > > > > class C { > > public: > > > > static C* make( /* ... */ ); > > static void free(C*); > > > > void f(); //whatever > > > > private: > > > > C(); > > C(const C&); > > > > ~C(); > > > > C& operator=(const C&); > > }; > > > > Here, the ctor (and dtor) is declared as private, so the only way to > > make a C object is by calling factory function C::make(). > > > > This has a direct translation into Ada95: > > > > package P is > > > > type T (<>) is limited private; > > > > procedure Op (O : in out T); > > > > type T_Access is access all T; > > > > function New_T (...) return T_Access; > > And this is why C++ is never a good guide to how to do things in Ada. > The pointer may well be needed in C++; Not in this case. class AD_Converter { private: AD_Converter(int line) {} public: static AD_Converter Noise; }; AD_Converter AD_Converter::Noise(17); ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-21 19:31 ` Kevin Cline @ 2004-10-21 22:02 ` Matthew Heaney 2004-10-22 0:10 ` Matthew Heaney 0 siblings, 1 reply; 55+ messages in thread From: Matthew Heaney @ 2004-10-21 22:02 UTC (permalink / raw) "Kevin Cline" <kevin.cline@gmail.com> wrote in message news:e749549b.0410211131.6505da@posting.google.com... > > class AD_Converter > { > private: > > AD_Converter(int line) {} > public: > static AD_Converter Noise; > }; > > AD_Converter AD_Converter::Noise(17); Yes, indeed. I should have made this more clear. Actually, directly translating the C++ code above to Ada is a little tricky, since you can't declare object Noise until the full view of the type has been declared. That's what motivated my use of a selector-style function to return a (constant) reference to the object declared in the body (or in the private part of the spec). But the real issue is that a function returns a constant reference, so if you want to be able to use an operation to actually modify the object you need to do something else. One way is to use the Rosen Trick: package AD_Converts is type AD_Converter (<>) is limited private; procedure Op (ADC : AD_Converter); --modifier function Noise return AD_Converter; private type Handle (ADC : access AD_Converter) is limited null record; type AD_Converter is limited record H : Handle (ADC'Access); end record; end; package body AD_Converters is procedure Op (ADC : AD_Converter) is X : AD_Converter renames ADC.H.ADC.all; begin ... -- modify X as desired end; ... end AD_Converters; Part of the problem is that we were given a requirement that we can't use access types. If we didn't have that requirement, then you do this: package AD_Converter is type AD_Converter (<>) is limited private; procedure Modifier (ADC : access AD_Converter); procedure Selector (ADC : access constant AD_Converter); type ADC_Access is access all AD_Converter; for ADC_Access'Storage_Size use 0; Noise : constant ADC_Access; private type AD_Converter is limited record ... end record; --no more Rosen Trick (sorry, Jean-Pierre...) Noise_ADC : aliased AD_Conveter; Noise : constant ADC_Access := Noise_ADC'Access; end; However, all we're really doing is using the AD_Converter type as a fancy way to identify a statically declared object. We have simpler ways of doing that, especially if the "object" is just an array component: package AD_Converters is type AD_Converter (<>) is limited private; procedure Modifier (ADC : in out AD_Converter); procedure Selector (ADC : in AD_Converter); Noise : constant AD_Converter; private type AD_Converter is new Positive; Noise : constant AD_Converter := 1; end; package body AD_Converters is type Rep_Type is limited record ... end record; Objects : array (AC_Converter range 1 .. <whatever>) of Rep_Type; procedure Modify (ADC : in out AD_Converter) is Object : Rep_Type renames Objects (ADC); begin ... end; ... end; ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-21 22:02 ` Matthew Heaney @ 2004-10-22 0:10 ` Matthew Heaney 0 siblings, 0 replies; 55+ messages in thread From: Matthew Heaney @ 2004-10-22 0:10 UTC (permalink / raw) "Matthew Heaney" <mheaney@on2.com> writes: > "Kevin Cline" <kevin.cline@gmail.com> wrote in message > news:e749549b.0410211131.6505da@posting.google.com... > > > > class AD_Converter > > { > > private: > > > > AD_Converter(int line) {} > > public: > > static AD_Converter Noise; > > }; > > > > AD_Converter AD_Converter::Noise(17); > > Yes, indeed. I should have made this more clear. > > Actually, directly translating the C++ code above to Ada is a little > tricky, since you can't declare object Noise until the full view of > the type has been declared. I realized on my drive home that I forgot this one: package AD_Converters is type AD_Converter (<>) is limited private; procedure Op (ADC : AD_Converter); Noise : constant AD_Converter; private type Rep_Type is limited record ... end record; type AD_Converter is access all Rep_Type; for AD_Converter'Storage_Size use 0; Noise_Object : aliased Rep_Type; Noise : constant AD_Converter := Noise_Object'Access; end AD_Converters; ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 7:24 ` Matthew Heaney 2004-10-20 8:39 ` Dmitry A. Kazakov 2004-10-21 1:36 ` Jeffrey Carter @ 2004-10-21 8:25 ` Martin Dowie 2 siblings, 0 replies; 55+ messages in thread From: Martin Dowie @ 2004-10-21 8:25 UTC (permalink / raw) Matthew Heaney wrote: > For reasons I can't fathom, many Ada95 developers still have a very > Ada83 mindset. The reasons for this are numerous - e.g. some of us still work with Ada83 projects on a daily basis, development processes for Ada95 projects may have been inherited with little or no change from previous projects. Changing implementation techniques to make to 'best use' of a language would also impact on the process and procedures for the design phase. Where a process is already in place and not obviously failing there may be little impitous, time or money to re-write these processes. Sometimes design processes are shared between projects working with different implementation languages - how do you do 'indefinite' in 'C'?.. I work for a CMM Level 5 company, so our processes are always undergoing improvement but this sort of change is much lower in the priority list than getting processing in place to get the best from our UML/CM/Change Control systems. It generally isn't out of dogma or badness or not wanting to do the 'right thing'. -- Martin ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 5:39 ` Simon Wright 2004-10-20 7:24 ` Matthew Heaney @ 2004-10-20 17:04 ` Matthew Heaney 2004-10-20 19:37 ` Simon Wright 1 sibling, 1 reply; 55+ messages in thread From: Matthew Heaney @ 2004-10-20 17:04 UTC (permalink / raw) "Simon Wright" <simon@pushface.org> wrote in message news:x7v4qkqrlr1.fsf@smaug.pushface.org... > > package body ADC is > > task type T is ... > type T_P is access T; > Converter_1 : T_P; > > begin > > Converter_1 := new T (...); > > end ADC; This doesn't buy you anything. The rule is that the "task object" elaborates in linear order (the same as for any other declaration), but then the "task" itself "activates" when the begin statement is reached. We can write your example as: package body ADC is task type T; O : T; -- this is the "task object" task body T is ... end; end; No explicit allocation is necessary. Task object O elaborates in the normal way, and its associated task activates at the completion of elaboration of the package body. The distinction between "task object" and "task", and between "elaboration" and "activation", is somewhat subtle. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 17:04 ` Matthew Heaney @ 2004-10-20 19:37 ` Simon Wright 2004-10-20 20:04 ` Matthew Heaney 0 siblings, 1 reply; 55+ messages in thread From: Simon Wright @ 2004-10-20 19:37 UTC (permalink / raw) "Matthew Heaney" <mheaney@on2.com> writes: > "Simon Wright" <simon@pushface.org> wrote in message > news:x7v4qkqrlr1.fsf@smaug.pushface.org... > > > > package body ADC is > > > > task type T is ... > > type T_P is access T; > > Converter_1 : T_P; > > > > begin > > > > Converter_1 := new T (...); > > > > end ADC; > > This doesn't buy you anything. The rule is that the "task object" > elaborates in linear order (the same as for any other declaration), but then > the "task" itself "activates" when the begin statement is reached. > > We can write your example as: > > package body ADC is > task type T; > > O : T; -- this is the "task object" > > task body T is ... end; > > end; > > No explicit allocation is necessary. Task object O elaborates in the normal > way, and its associated task activates at the completion of elaboration of > the package body. And this is exactly why you end up with elaboration order problems! package A is procedure P; end A; with B; package body A is procedure P is begin null; end P; end A; package B is procedure Q; end B; with A; package body B is task type T is entry Start; end T; O : T; task body T is begin accept Start; A.P; end T; procedure Q is begin null; end Q; end B; with A; procedure M is begin null; end M; smaug.pushface.org[7]$ gnatmake m gcc -c m.adb gcc -c a.adb gcc -c b.adb gnatbind -x m.ali error: elaboration circularity detected info: "b (body)" must be elaborated before "b (body)" info: reason: implicit Elaborate_All in unit "b (body)" info: recompile "b (body)" with -gnatwl for full details info: "b (body)" info: must be elaborated along with its spec: info: "b (spec)" info: which is withed by: info: "a (body)" info: which must be elaborated along with its spec: info: "a (spec)" info: which is withed by: info: "b (body)" gnatmake: *** bind failed. -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 19:37 ` Simon Wright @ 2004-10-20 20:04 ` Matthew Heaney 2004-10-22 5:37 ` Simon Wright 0 siblings, 1 reply; 55+ messages in thread From: Matthew Heaney @ 2004-10-20 20:04 UTC (permalink / raw) "Simon Wright" <simon@pushface.org> wrote in message news:x7voeixb2pl.fsf@smaug.pushface.org... > > And this is exactly why you end up with elaboration order problems! > > with A; > package body B is ...; This needs to say: with A; pragma Elaborate (A); package body B is ...; And now all is well. The problem is that without the pragma, your compile assumes Elaborate_All. But this is too strong, since A has a dependency on B. By explicitly using pragma Elaborate, this only elaborates package A. The elaboration order is thus: A spec B spec A body B body This is one of those few times when you need Elaborate, not Elaborate_All. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 20:04 ` Matthew Heaney @ 2004-10-22 5:37 ` Simon Wright 0 siblings, 0 replies; 55+ messages in thread From: Simon Wright @ 2004-10-22 5:37 UTC (permalink / raw) "Matthew Heaney" <mheaney@on2.com> writes: > This is one of those few times when you need Elaborate, not > Elaborate_All. I suppose (as a GNAT user) I see having to mention Elaborate at all as being a problem! I'm sure I've seen cases where no amount of fiddling helped ... but I can't find them now, so better leave it. -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-19 3:28 ` Matthew Heaney 2004-10-19 12:53 ` Marin David Condic @ 2004-10-20 1:10 ` Jeffrey Carter 2004-10-20 7:04 ` Matthew Heaney 1 sibling, 1 reply; 55+ messages in thread From: Jeffrey Carter @ 2004-10-20 1:10 UTC (permalink / raw) Matthew Heaney wrote: > Too much code bloat. There's no reason AD_Converter needs to be a > generic, if the objects of that type are known apriori: Perhaps. The Ada idiom for a singleton is package-as-object; the obvious extension from "single" to "a few" is a generic package. However, a discriminated type such as you described may well be a viable alternative. It's the idea that you need a family of tagged types, type extension, and all that entails for something this simple. I would expect, in any case, that these things are the low-level interface to the devices, and that the application would use higher-level interfaces that map the range of values the device deals with to information meaningful to the application. -- Jeff Carter "Spam! Spam! Spam! Spam! Spam! Spam! Spam! Spam!" Monty Python's Flying Circus 53 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 1:10 ` Jeffrey Carter @ 2004-10-20 7:04 ` Matthew Heaney 2004-10-20 12:42 ` Marin David Condic 0 siblings, 1 reply; 55+ messages in thread From: Matthew Heaney @ 2004-10-20 7:04 UTC (permalink / raw) Jeffrey Carter <spam@spam.com> writes: > The Ada idiom for a singleton is package-as-object; the obvious > extension from "single" to "a few" is a generic package. That might have been true in Ada83, but it is not true in Ada95. The intended Ada95 mechanism for controlling instance creation is to declare the type as limited and indefinite, and for the package to provide a factory function to create instances of the type. > However, a discriminated type such as you described may well be a > viable alternative. It's the idea that you need a family of tagged > types, type extension, and all that entails for something this simple. The original problem had to do with where and how to declare well-known objects. That problem is orthogonal to the need for type extension and dynamic binding. If you don't need type extension or dynamic binding, then clearly the type doesn't need to be tagged. See the genealogy directories in ai302/examples at the tigris site for some examples. Actually, I realized after I had written genealogy2 that I should have implemented the parser like this: package Parser is type Data_Type (<>) is limited private; function Student (Data : Data_Type) return String; function Advisor (Data : Data_Type) return String; ... procedure Iterate (Process : not null access procedure (Data : Data_Type)); ... end Parser; Here's a case where the instances are created by the package on-the-fly, as the passive iteration occurs. None of the types declared in Data_Maps or Relation_Maps are tagged, but they are all limited and indefinite. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 7:04 ` Matthew Heaney @ 2004-10-20 12:42 ` Marin David Condic 2004-10-20 12:55 ` Matthew Heaney 2004-10-20 15:27 ` Matthew Heaney 0 siblings, 2 replies; 55+ messages in thread From: Marin David Condic @ 2004-10-20 12:42 UTC (permalink / raw) In my particular example, I have outlawed the use of access types. It doesn't matter why. You can get a perfectly good static allocation of exactly what is needed with the plain vanilla object declaration ala: Some_Object : Class_Package.Tagged_Record_Type ; I don't find a problem with that. It is simple and enables me to get exactly what I need from the compiler, linker and other tools down the chain. The question is "Where do you put it?" Dimitri seems to like a child package under the "class" package. I've used that in the past. It works fine, but does proliferate packages. There might be some variations on that (one "object" per child package versus all "objects" in one child package?) There are other spots to declare such entities and I'm wondering what is preferred by most Ada people who actually declare some static (library level) 'objects'? MDC Matthew Heaney wrote: > > The intended Ada95 mechanism for controlling instance creation is to > declare the type as limited and indefinite, and for the package to > provide a factory function to create instances of the type. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Power corrupts. Absolute power is kind of neat" -- John Lehman, Secretary of the Navy 1981-1987 ====================================================================== ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 12:42 ` Marin David Condic @ 2004-10-20 12:55 ` Matthew Heaney 2004-10-20 15:27 ` Matthew Heaney 1 sibling, 0 replies; 55+ messages in thread From: Matthew Heaney @ 2004-10-20 12:55 UTC (permalink / raw) Marin David Condic <nobody@noplace.com> writes: > In my particular example, I have outlawed the use of access types. It > doesn't matter why. You can get a perfectly good static allocation of > exactly what is needed with the plain vanilla object declaration ala: > > Some_Object : Class_Package.Tagged_Record_Type ; I technique I have described doesn't require access types. If the type is limited, then it gets passed by reference, so you don't need an explicit access type. You still haven't explained why your type above is tagged, or why it is nonlimited. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 12:42 ` Marin David Condic 2004-10-20 12:55 ` Matthew Heaney @ 2004-10-20 15:27 ` Matthew Heaney 2004-10-21 1:36 ` Matthew Heaney 1 sibling, 1 reply; 55+ messages in thread From: Matthew Heaney @ 2004-10-20 15:27 UTC (permalink / raw) "Marin David Condic" <nobody@noplace.com> wrote in message news:P2tdd.3504$ta5.1130@newsread3.news.atl.earthlink.net... > > In my particular example, I have outlawed the use of access types. It > doesn't matter why. If you want to outlaw dynamic allocation, that's one thing. But if you want to outlaw access types, that's another thing. I showed in an earlier post how to use access types, but hide the fact that access types are used: package P is type T (<>) is limited private; procedure Op (O : in T); function O1 return T; function O2 return T; private type Rep_Type is limited ... end record; type T is access all Rep_Type; for T'Storage_Size use 0; end P; ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 15:27 ` Matthew Heaney @ 2004-10-21 1:36 ` Matthew Heaney 0 siblings, 0 replies; 55+ messages in thread From: Matthew Heaney @ 2004-10-21 1:36 UTC (permalink / raw) "Matthew Heaney" <mheaney@on2.com> writes: > I showed in an earlier post how to use access types, but hide the fact > that access types are used: > > package P is > type T (<>) is limited private; > procedure Op (O : in T); > function O1 return T; > function O2 return T; > private > type Rep_Type is limited ... end record; > > type T is access all Rep_Type; > for T'Storage_Size use 0; > end P; Actually, I forgot to mention that you don't need an access type if you use an array to hold the objects: package P is type T (<>) is limited private; procedure Op (O : in T); function O1 return T; function O2 return T; private type T is range 1 .. 2; end P; package body P is type Rep_Type is limited record ... end record; Objects : Rep_Type (T); procedure Op (O : in T) is OO : Rep_Type renames Objects (O); begin ... end; function O1 return T is begin return 1; end; function O2 return T is begin return 2; end; end P; In fact, you don't need the private type at all: package P is type T is (O1, O2); procedure Op (O : in T); end P; package body P is type Rep_Type is limited record ... end record; Objects : Rep_Type (T); procedure Op (O : in T) is OO : Rep_Type renames Objects (O); begin ... end; end P; ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-18 12:26 ` Marius Amado Alves 2004-10-19 2:09 ` Jeffrey Carter @ 2004-10-19 12:38 ` Marin David Condic 1 sibling, 0 replies; 55+ messages in thread From: Marin David Condic @ 2004-10-19 12:38 UTC (permalink / raw) Well, that's one approach. I'd prefer to avoid the code bloat of a generic when all I really need to duplicate is the data. Also, its tougher to do any sort of inheritance going the generic route. I'm wondering specifically about the usual OOD idiom of making a class out of a package with a tagged record - such that it can be extended with another child class - and where is the "best" place to declare objects of that class? MDC Marius Amado Alves wrote: >> Suppose I have a class with one or a limited set of objects. The >> objects are "global" in the sense that they hang around from program >> startup thru the entire life of execution. An example would be an A/D >> Converter class - My little control box might have 3 or 4 A/Ds in it - >> they're always there and I want the data associated with them to be >> static (not declared on the stack.) >> >> Question: What is the preferred Ada idiom for defining such a creature? > > > generic > Line : Number; > package AD_Converter is > function OK return Boolean; > function Get return Value; > end; > > package Heat is new AD_Converter (123); > package Noise is new AD_Converter (456); > package Wind is new AD_Converter (789); > > -- You can't get more "static" than that! > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Power corrupts. Absolute power is kind of neat" -- John Lehman, Secretary of the Navy 1981-1987 ====================================================================== ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-18 11:47 Idiom for a class and an object in Ada Marin David Condic 2004-10-18 12:14 ` Martin Krischik 2004-10-18 12:26 ` Marius Amado Alves @ 2004-10-18 16:59 ` Matthew Heaney 2004-10-18 18:02 ` Martin Dowie 2004-10-20 16:20 ` Michael Paus 4 siblings, 0 replies; 55+ messages in thread From: Matthew Heaney @ 2004-10-18 16:59 UTC (permalink / raw) "Marin David Condic" <nobody@noplace.com> wrote in message news:M3Ocd.237$5i5.72@newsread2.news.atl.earthlink.net... > Suppose I have a class with one or a limited set of objects. The objects > are "global" in the sense that they hang around from program startup > thru the entire life of execution. An example would be an A/D Converter > class - My little control box might have 3 or 4 A/Ds in it - they're > always there and I want the data associated with them to be static (not > declared on the stack.) > > Question: What is the preferred Ada idiom for defining such a creature? See for example the packages Data_Maps and Relation_Maps in the genealogy examples in the ai302 examples subdirectory: <http://charles.tigris.org/source/browse/charles/src/ai302/examples/genealog y/> The idea is to create a limited private type with an unknown discriminant: package Data_Maps is type Map (<>) is limited private; ... -- operations here function Dates return Map; function Places return Map; private ... -- see code for implementation end; This is similar to how Standard_Input, Standard_Output, etc are implemented in Text_IO. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-18 11:47 Idiom for a class and an object in Ada Marin David Condic ` (2 preceding siblings ...) 2004-10-18 16:59 ` Matthew Heaney @ 2004-10-18 18:02 ` Martin Dowie 2004-10-19 13:06 ` Marin David Condic 2004-10-20 16:20 ` Michael Paus 4 siblings, 1 reply; 55+ messages in thread From: Martin Dowie @ 2004-10-18 18:02 UTC (permalink / raw) > Does anybody have an opinion or experience with doing this? I know > what I've done in the past, but I'm curious if there is any preferred > method or idiom for this in the OO paradigm as applied to Ada? I tend to use Ward-Mellor RTSA/OOD as a method which leaves me with a number of "project specific" processes on static data. But the data type also leads to project specific classes (or ADT) which may be based on more general classes (e.g. containers). e.g. package General_Classes is -- Most re-usable type Class is private; end General_Classes; with General_Classes; package Project_Classes is -- Less re-usable type Class is private; procedure Process_1 (C : in out Class); procedure Process_2 (C : in out Class; I : Integer); private type Class is new General_Classes.Class with ...; end Project_Classes; package Project_Objects is -- Least re-usable procedure Process_1; -- Each process maps to a RTSA process (or a UML use-case) procedure Process_2; end Project_Objects; with Project_Classes; package body Project_Objects is Objects : Project_Classes.Class; -- Safely hidden data... procedure Process_1 is ... procedure Process_2 is ... end Project_Objects; It maps requirements to design to code very well. $0.02 -- Martin --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.778 / Virus Database: 525 - Release Date: 15/10/2004 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-18 18:02 ` Martin Dowie @ 2004-10-19 13:06 ` Marin David Condic 2004-10-19 14:51 ` Martin Dowie 0 siblings, 1 reply; 55+ messages in thread From: Marin David Condic @ 2004-10-19 13:06 UTC (permalink / raw) Interesting, but I think it misses my question. In your first package: General_Classes - if you had 5 specific objects of type Class and they are totally static (something that exists from the moment you hit the first instruction to the moment the power goes down and you *really* need them to be in global memory) - where would you declare the five objects of type "Class" as you've defined it? How to do it is simple: Object_1 : General_Classes.Class ; Object_2 : General_Classes.Class ; Object_3 : General_Classes.Class ; Object_4 : General_Classes.Class ; Object_5 : General_Classes.Class ; In what context would you put those objects? MDC Martin Dowie wrote: >>Does anybody have an opinion or experience with doing this? I know >>what I've done in the past, but I'm curious if there is any preferred >>method or idiom for this in the OO paradigm as applied to Ada? > > > I tend to use Ward-Mellor RTSA/OOD as a method which leaves me with a number > of "project specific" processes on static data. But the data type also leads > to project specific classes (or ADT) which may be based on more general > classes (e.g. containers). e.g. > > package General_Classes is -- Most re-usable > type Class is private; > end General_Classes; > > with General_Classes; > package Project_Classes is -- Less re-usable > type Class is private; > procedure Process_1 (C : in out Class); > procedure Process_2 (C : in out Class; I : Integer); > private > type Class is new General_Classes.Class with ...; > end Project_Classes; > > package Project_Objects is -- Least re-usable > procedure Process_1; -- Each process maps to a RTSA process (or a UML > use-case) > procedure Process_2; > end Project_Objects; > > with Project_Classes; > package body Project_Objects is > Objects : Project_Classes.Class; -- Safely hidden data... > procedure Process_1 is ... > procedure Process_2 is ... > end Project_Objects; > > It maps requirements to design to code very well. > > $0.02 > > -- Martin > > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.778 / Virus Database: 525 - Release Date: 15/10/2004 > > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Power corrupts. Absolute power is kind of neat" -- John Lehman, Secretary of the Navy 1981-1987 ====================================================================== ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-19 13:06 ` Marin David Condic @ 2004-10-19 14:51 ` Martin Dowie 0 siblings, 0 replies; 55+ messages in thread From: Martin Dowie @ 2004-10-19 14:51 UTC (permalink / raw) Marin David Condic wrote: > Interesting, but I think it misses my question. In your first package: > General_Classes - if you had 5 specific objects of type Class and they > are totally static (something that exists from the moment you hit the > first instruction to the moment the power goes down and you *really* > need them to be in global memory) - where would you declare the five > objects of type "Class" as you've defined it? > > How to do it is simple: > > Object_1 : General_Classes.Class ; > Object_2 : General_Classes.Class ; > Object_3 : General_Classes.Class ; > Object_4 : General_Classes.Class ; > Object_5 : General_Classes.Class ; > > In what context would you put those objects? Inside a package body with access routines. These routines tend to be the project-specific ones. They /may/ be portable to other systems but are less likely to be portable than a class that models the behaviour of those types of registers. But in your 5 A-D examples, and assuming that the 5 A-D were on a particular device, I would consider make the package name the device name. If there was some issue with having to assign the registers into a processors particular area of memory that couldn't be done via an address clause but could only be done via a compiler/linker command, then I have separated out the data items into their own package spec - to avoid the access routines also being mapped into that area. The package names were suffixed "_GD" (for Global Data) and the coding rules were that only the package without the "_GD" could 'with' them and then only from the package body. -- Martin ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-18 11:47 Idiom for a class and an object in Ada Marin David Condic ` (3 preceding siblings ...) 2004-10-18 18:02 ` Martin Dowie @ 2004-10-20 16:20 ` Michael Paus 2004-10-20 17:15 ` Matthew Heaney 2004-10-21 12:33 ` Marin David Condic 4 siblings, 2 replies; 55+ messages in thread From: Michael Paus @ 2004-10-20 16:20 UTC (permalink / raw) Hi Marin, your question has triggered an interesting discussion which I found very amusing. Before I provide my proposal for a solution of your problem I think it is essential to first discuss what the potential benefits of your OO approach are. You have chosen to use a tagged type to represent your A/D converters which I think is a wise decision but neither you nor anybody else seems to be able to give a good reason for that (if I have not missed it :-) and also in the way you have started you are missing an opportunity for flexibility in your design and for really exploiting your OO approach. First of all your A/D converter class should be abstract and in all places where you later access an A/D converter you should only refer to this abstract base class. This gives you the possibility to easily exchange the implementation of your A/D converter by providing different implementations of sub-classes of your base class. The decision of which implementation you want to use can even be done at run-time if you like. E.g., I often use this technique to provide one sub-class for the real hardware and one which is only linked to a simulation device which is connected via ethernet. I think this makes the potential benefit of the OO approach clear. Now that the goal is clearer it is easier to find a solution for your original question. I like to be able to put together different configurations of my software. E.g., one that is configured to run on the target and another one which is used for a PC based simulation of the software and I want to change as little of the software as necessary to create a new configuration. I therefore have a configuration specific main program and also a configuration specific package which only has an "Initialize" and a "Start" procedure. As this package is configuration specific no other package is allowed to access this package. In this package I declare all the top level and configuration specific objects statically and if some object needs another object I pass in a class wide access value to the corresponding object in the "Initialize" method. Alternatively you can also provide abstract factory packages for these objects. This is useful in cases where an instance of these objects is used in many places of your software. From a reusability point of view it is important that you keep the creation of instances separate from the objects which use them. For me this approach has worked very well and it even has some more advantages which I have not discussed here. Yours Michael ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 16:20 ` Michael Paus @ 2004-10-20 17:15 ` Matthew Heaney 2004-10-20 17:55 ` Michael Paus 2004-10-21 12:33 ` Marin David Condic 1 sibling, 1 reply; 55+ messages in thread From: Matthew Heaney @ 2004-10-20 17:15 UTC (permalink / raw) "Michael Paus" <pausnospam@nospamib-paus.com> wrote in message news:cl6395$g1l$1@online.de... > > You have chosen to use a tagged type to represent your A/D converters > which I think is a wise decision but neither you nor anybody else > seems to be able to give a good reason for that (if I have not missed it > :-) > and also in the way you have started you are missing an opportunity > for flexibility in your design and for really exploiting your OO approach. How are you able to evaluate whether the use of a tagged type is a "wise decision" unless you have been given reasons why the type is tagged? My judgement about the fact that the type is tagged and nonlimited is that this is a very *unwise* decision. There is no reason for the type to be tagged unless you need type extension or dynamic binding. There is no reason why the global objects' type should have assignment. There is no reason why the global objects' type should allow anyone to create instances anywhere. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 17:15 ` Matthew Heaney @ 2004-10-20 17:55 ` Michael Paus 0 siblings, 0 replies; 55+ messages in thread From: Michael Paus @ 2004-10-20 17:55 UTC (permalink / raw) Matthew Heaney wrote: > "Michael Paus" <pausnospam@nospamib-paus.com> wrote in message > news:cl6395$g1l$1@online.de... > >>You have chosen to use a tagged type to represent your A/D converters >>which I think is a wise decision but neither you nor anybody else >>seems to be able to give a good reason for that (if I have not missed it >>:-) >>and also in the way you have started you are missing an opportunity >>for flexibility in your design and for really exploiting your OO approach. > > > How are you able to evaluate whether the use of a tagged type is a "wise > decision" unless you have been given reasons why the type is tagged? According to my experience in similar situations the use of tagged types offers more flexibility than other approaches and I therefore think it is a wise decision. > My judgement about the fact that the type is tagged and nonlimited is that > this is a very *unwise* decision. Your opinion without an explanation. > There is no reason for the type to be tagged unless you need type extension > or dynamic binding. I think I have explained already why you do need type extension here. > There is no reason why the global objects' type should have assignment. I did not say anything about assignment. > There is no reason why the global objects' type should allow anyone to > create instances anywhere. I also did not say anthing about that. You can hide that in a factory package. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada 2004-10-20 16:20 ` Michael Paus 2004-10-20 17:15 ` Matthew Heaney @ 2004-10-21 12:33 ` Marin David Condic 1 sibling, 0 replies; 55+ messages in thread From: Marin David Condic @ 2004-10-21 12:33 UTC (permalink / raw) I chose the A/D converter example because I needed to think of something that exists statically in some fixed number within a system and is highly unlikely to change over time. I might have gone political and used "Senate Seats" since there are only 50 of them and (depending on the application in mind) will likely be some kind of fixed objects from start to finish. I'm really sorry people got wrapped around the axle of the A/D stuff because I was looking for a more general answer to a more general question about OO Programming in Ada. That said, I thought your remarks were well thought out anyway. ;-) MDC Michael Paus wrote: > You have chosen to use a tagged type to represent your A/D converters > which I think is a wise decision but neither you nor anybody else > seems to be able to give a good reason for that (if I have not missed it > :-) > and also in the way you have started you are missing an opportunity > for flexibility in your design and for really exploiting your OO approach. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Power corrupts. Absolute power is kind of neat" -- John Lehman, Secretary of the Navy 1981-1987 ====================================================================== ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Idiom for a class and an object in Ada
@ 2004-10-21 13:59 Stephen Leake
0 siblings, 0 replies; 55+ messages in thread
From: Stephen Leake @ 2004-10-21 13:59 UTC (permalink / raw)
To: comp.lang.ada
Matthew Heaney <matthewjheaney@earthlink.net> writes:
> Jeffrey Carter <spam@spam.com> writes:
>
> > Matthew Heaney wrote:
> >
> > > For reasons I can't fathom, many Ada95 developers still have a very
> > > Ada83 mindset.
> >
> > That's because Ada 83 was a very good language, and the idioms that were
> > good for it are still good.
>
> Ancient history.
The mere fact that something is _ancient_ doesn't mean it's _bad_.
Here are some truly ancient facts:
2 + 2 = 4
a**2 + b**2 = c**2
F = M a
Will you dismiss those in the same way?
Please give real reasons why Ada 83 idioms are no longer useful.
--
-- Stephe
___________________________________________________________
This mail sent using ToadMail -- Web based e-mail @ ToadNet
^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2004-10-22 5:37 UTC | newest] Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-10-18 11:47 Idiom for a class and an object in Ada Marin David Condic 2004-10-18 12:14 ` Martin Krischik 2004-10-18 19:40 ` Matthew Heaney 2004-10-19 12:59 ` Marin David Condic 2004-10-19 14:46 ` Martin Dowie 2004-10-19 15:55 ` Matthew Heaney 2004-10-19 18:31 ` Martin Dowie 2004-10-19 15:52 ` Matthew Heaney 2004-10-18 12:26 ` Marius Amado Alves 2004-10-19 2:09 ` Jeffrey Carter 2004-10-19 3:28 ` Matthew Heaney 2004-10-19 12:53 ` Marin David Condic 2004-10-19 14:44 ` Matthew Heaney 2004-10-19 15:01 ` Dmitry A. Kazakov 2004-10-19 15:40 ` Matthew Heaney 2004-10-20 7:58 ` Dmitry A. Kazakov 2004-10-20 12:31 ` Marin David Condic 2004-10-20 13:53 ` Dmitry A. Kazakov 2004-10-20 15:23 ` Matthew Heaney 2004-10-21 12:24 ` Marin David Condic 2004-10-21 17:15 ` Matthew Heaney 2004-10-20 5:39 ` Simon Wright 2004-10-20 7:24 ` Matthew Heaney 2004-10-20 8:39 ` Dmitry A. Kazakov 2004-10-21 1:36 ` Jeffrey Carter 2004-10-21 1:46 ` Matthew Heaney 2004-10-21 7:51 ` Dmitry A. Kazakov 2004-10-21 12:45 ` Matthew Heaney 2004-10-21 14:11 ` Dmitry A. Kazakov 2004-10-22 1:04 ` Jeffrey Carter 2004-10-22 1:36 ` Matthew Heaney 2004-10-21 19:31 ` Kevin Cline 2004-10-21 22:02 ` Matthew Heaney 2004-10-22 0:10 ` Matthew Heaney 2004-10-21 8:25 ` Martin Dowie 2004-10-20 17:04 ` Matthew Heaney 2004-10-20 19:37 ` Simon Wright 2004-10-20 20:04 ` Matthew Heaney 2004-10-22 5:37 ` Simon Wright 2004-10-20 1:10 ` Jeffrey Carter 2004-10-20 7:04 ` Matthew Heaney 2004-10-20 12:42 ` Marin David Condic 2004-10-20 12:55 ` Matthew Heaney 2004-10-20 15:27 ` Matthew Heaney 2004-10-21 1:36 ` Matthew Heaney 2004-10-19 12:38 ` Marin David Condic 2004-10-18 16:59 ` Matthew Heaney 2004-10-18 18:02 ` Martin Dowie 2004-10-19 13:06 ` Marin David Condic 2004-10-19 14:51 ` Martin Dowie 2004-10-20 16:20 ` Michael Paus 2004-10-20 17:15 ` Matthew Heaney 2004-10-20 17:55 ` Michael Paus 2004-10-21 12:33 ` Marin David Condic -- strict thread matches above, loose matches on Subject: below -- 2004-10-21 13:59 Stephen Leake
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox