* Re: Self-referential types [not found] <7ttb4a$8mq$1@nnrp1.deja.com> @ 1999-10-12 0:00 ` Robert A Duff 1999-10-12 0:00 ` Vladimir Olensky [not found] ` <3802597B.9205AEE8@averstar.com> 2 siblings, 0 replies; 62+ messages in thread From: Robert A Duff @ 1999-10-12 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > I'm trying to create my first self referential type. But there's > obviously something about this technique I'm missing, because all > attempts produce compiler errors in multiple compilers. > > Below is a code sample that is taken directly from Cohen's AAASL, > section 11.8.3: > > procedure Test is > > type Cell_Type; > > type List_Type is access all Cell_Type; > > type Cell_Type is > limited record > Contents_Part : String (1..20); > Next_Cell_Part : List_Type := Cell_Type'Access; > Previous_Cell_Part : List_Type := Cell_Type'Access; > end record; > begin > null; > end Test; > > Compiling this with Gnat gives me: > Test.adb:10:43: non-local pointer cannot point to local object > Test.adb:11:43: non-local pointer cannot point to local object > > I don't see an accesability level problem here, ... X: List_Type; procedure Nested is Local: Cell_Type; begin X := Local.Next_Cell_Part; end Nested; Nested; ... X.all ... -- Here, X is a dangling pointer. That's the accessibility level problem. You need to use 'Unchecked_Access, and you need to be careful not to do the above. The language design tries to prevent dangling pointers unless you do something "unchecked". >...and it looks like it > thinks Cell_Type is an object, not a type. It *is* an object -- the "current instance" of the type (sort of like "self" or "this" in some other languages). - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types [not found] <7ttb4a$8mq$1@nnrp1.deja.com> 1999-10-12 0:00 ` Self-referential types Robert A Duff @ 1999-10-12 0:00 ` Vladimir Olensky 1999-10-12 0:00 ` Matthew Heaney [not found] ` <3802597B.9205AEE8@averstar.com> 2 siblings, 1 reply; 62+ messages in thread From: Vladimir Olensky @ 1999-10-12 0:00 UTC (permalink / raw) Ted Dennison wrote in message <7ttb4a$8mq$1@nnrp1.deja.com>... >I'm trying to create my first self referential type. But there's >obviously something about this technique I'm missing, because all >attempts produce compiler errors in multiple compilers. > >Below is a code sample that is taken directly from Cohen's AAASL, >section 11.8.3: > >procedure Test is > > type Cell_Type; > > type List_Type is access all Cell_Type; > > type Cell_Type is > limited record > Contents_Part : String (1..20); > Next_Cell_Part : List_Type := Cell_Type'Access; > Previous_Cell_Part : List_Type := Cell_Type'Access; > end record; >begin > null; >end Test; It seems that this example was not tested. How it is possible to initialize access variable by the initial value that is access attribute to type ? Access attributes can not be applied to type. It may only be applied to some object but not to its description. Also compiles are probably giving misleading error messages. If you change your example to: ------------------------------------- Procedure Test is type Cell_Type; type List_Type is access all Cell_Type; type Cell_Type is limited record Contents_Part : String (1..20); Next_Cell_Part : List_Type := null; Previous_Cell_Part : List_Type := null; end record; Wrong_Initialization : List_Type := Cell_Type'Access; begin null; end Test; ------------------------------------------ than you will have right error message regarding Wrong_Initialization varible: >>>test.adb:14:37: "Access" attribute cannot be applied to type gnatmake: "test.adb" compilation error Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Vladimir Olensky @ 1999-10-12 0:00 ` Matthew Heaney 1999-10-12 0:00 ` Richard D Riehle ` (3 more replies) 0 siblings, 4 replies; 62+ messages in thread From: Matthew Heaney @ 1999-10-12 0:00 UTC (permalink / raw) In article <s04ql7cqh1s45@corp.supernews.com> , "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > How it is possible to initialize access variable > by the initial value that is access attribute to type ? Yes, of course it's possible to initialize an access object that is an access to a type! For a limited type T, then inside the declaration of the type, the expression T'Access refers to the "current instance" of the type. This is something a lot of programmers haven't learned yet. This is the basis for programming with access discriminants, which is how you do MI in Ada95. For example: type Handle_Type (Stack : access Stack_Type) is limited null record; type Stack_Type is limited record Handle : Handle_Type (Stack_Type'Access); --!!! <other stuff> end record; Here's another example: type T is tagged limited private; ... private function Do_Get_Default (O : T) return T2; function Get_Default (O : T'Class) return T2; type T is tagged limited record O : T2 := Get_Default (T'Access); --!!! end record; Where function Get_Default (O : T'Class) return T2 is begin return Do_Get_Default (O); end; This is the idiom you use if you want to let a descendent type change the default of component declared by the ancestor. > Access attributes can not be applied to type. Wrong. > It may only be applied to some object but not to its description. Wrong. > Also compiles are probably giving misleading error messages. No, the compiler was correct. -- The new standards [for science curricula in Kansas] do not forbid the teaching of evolution, but the subject will no longer be included in statewide tests for evaluating students--a virtual guarantee, given the realities of education, that this central concept of biology will be diluted or eliminated, thus reducing courses to something like chemistry without the periodic table, or American history without Lincoln. Stephen Jay Gould, Time, 23 Aug 1999 ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Matthew Heaney @ 1999-10-12 0:00 ` Richard D Riehle 1999-10-12 0:00 ` news.oxy.com ` (2 subsequent siblings) 3 siblings, 0 replies; 62+ messages in thread From: Richard D Riehle @ 1999-10-12 0:00 UTC (permalink / raw) In article <3802f2db_2@news1.prserv.net>, "Matthew Heaney" <matthew_heaney@acm.org> wrote: >Yes, of course it's possible to initialize an access object that is an >access to a type! Matthew is correct about this. I have several examples of this in Ada book I am writing. Here is an pared down version of one of them fully coded with specification, body, and a little test program. generic type Item is private; package Access_Discriminant_2 is type Outer is limited private; type Outer_Reference is access all Outer; procedure Initialize (Data : in out Outer; FV : Float := 0.0; IV : Integer := 0); function Flag_Is (Data : Outer) return Natural; function Sentinel_Is (Data : Outer) return Float; private type Inner; type Inner (Outer_Link : access Outer) is limited record Inner_Value : Float := 0.0; end record; procedure Initialize (Data : in out Inner; V : Integer := 0); type Outer is limited record Outer_Data : Inner(Outer_Link => Outer'Access); Flag : Natural := 0; end record; end Access_Discriminant_2; with the following package body, package body Access_Discriminant_2 is procedure Initialize (Data : in out Outer; FV : Float := 0.0; IV : Integer := 0) is begin Data.Outer_Data.Inner_Value := 0.0; Initialize(Data.Outer_Data, V => IV); end Initialize; procedure Initialize (Data : in out Inner; V : Integer := 0) is begin Data.Outer_Link.Flag := V; end; function Flag_Is (Data : Outer) return Natural is begin return Data.Flag; end Flag_Is; function Sentinel_Is (Data : Outer) return Float is begin return Data.Outer_Data.Inner_Value; end Sentinel_Is; end Access_Discriminant_2; and this little program that shows how to use it, with Access_Discriminant_2; procedure Test_Access_Discriminant_2 is package Access_Demonstration is new Access_discriminant_2 (Item => Float); type Reference is access all Access_Demonstration.Outer; Outer_Data : aliased Access_Demonstration.Outer; Outer_Reference : Reference := Outer_Data'Access; begin Access_Demonstration.Initialize(Outer_Reference.all, FV => 14.2, IV => 42); end Test_Access_Discriminant_2; This example is one of a series that demonstrates variations on the theme, including ideas regarding improved encapsulation, and circumstances under which it can be appropriate in design. As to the notion of multiple-inheritance, most attempts to implement MI in Ada are no where close to true MI, including this one. However, this one is a pretty good composition mechanism for achieving other important design requirements. Richard Riehle ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Matthew Heaney 1999-10-12 0:00 ` Richard D Riehle @ 1999-10-12 0:00 ` news.oxy.com 1999-10-12 0:00 ` Ted Dennison 1999-10-12 0:00 ` Self-referential types Matthew Heaney 1999-10-12 0:00 ` Ted Dennison 1999-10-12 0:00 ` Robert I. Eachus 3 siblings, 2 replies; 62+ messages in thread From: news.oxy.com @ 1999-10-12 0:00 UTC (permalink / raw) Matthew Heaney wrote in message <3802f2db_2@news1.prserv.net>... >In article <s04ql7cqh1s45@corp.supernews.com> , "Vladimir Olensky" ><vladimir_olensky@yahoo.com> wrote: > >> How it is possible to initialize access variable >> by the initial value that is access attribute to type ? > >Yes, of course it's possible to initialize an access object that is an >access to a type! > >For a limited type T, then inside the declaration of the type, the >expression T'Access refers to the "current instance" of the type. Very good clarification indeed. >This is something a lot of programmers haven't learned yet. Let alone people which primary occupation is not programming ( as for me my primary occupation is telecommunications). >This is the basis for programming with access discriminants, which is >how you do MI in Ada95. > >For example: > > type Handle_Type (Stack : access Stack_Type) is > limited null record; > > type Stack_Type is > limited record > Handle : Handle_Type (Stack_Type'Access); --!!! > <other stuff> > end record; > > >Here's another example: > > type T is tagged limited private; >... >private > > function Do_Get_Default (O : T) return T2; > > function Get_Default (O : T'Class) return T2; > > type T is > tagged limited record > O : T2 := Get_Default (T'Access); --!!! > end record; > > >Where > > function Get_Default (O : T'Class) return T2 is > begin > return Do_Get_Default (O); > end; > > >This is the idiom you use if you want to let a descendent type change >the default of component declared by the ancestor. > All this is very interesting indeed. As for me I never used such thing and was not sure that it makes any sense to apply access attrubute to anything except oject instance. In other languages there exists "Self" parameter and when it is used in class declarations it refers to current class instance. You might put a short article regarding this issue to Adapower. I am sure it will be very useful. >> Access attributes can not be applied to type. >Wrong. It is wrong only for limited types. For types that are not limited it is true. >> It may only be applied to some object but not to its description. >Wrong. The same as above. For non limited types compiler gives you an error message: ------------------------------------------------------ Wrong_Initialization : List_Type := Cell_Type'Access; test.adb:14:37: "Access" attribute cannot be applied to type gnatmake: "test.adb" compilation error ----------------------------------------------------------------- This can make one think that it is always true . If GNAT would give you additional info that such construct could be applied only to limited types this could make person to look deeper to that (at least out of curiosity ). Again thanks for good clarification. It is very useful. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` news.oxy.com @ 1999-10-12 0:00 ` Ted Dennison 1999-10-12 0:00 ` Stanley R. Allen ` (2 more replies) 1999-10-12 0:00 ` Self-referential types Matthew Heaney 1 sibling, 3 replies; 62+ messages in thread From: Ted Dennison @ 1999-10-12 0:00 UTC (permalink / raw) In article <s06ji18vh1s47@corp.supernews.com>, "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote: > > Matthew Heaney wrote in message <3802f2db_2@news1.prserv.net>... > >This is the basis for programming with access discriminants, which is > >how you do MI in Ada95. > You might put a short article regarding this issue to Adapower. > I am sure it will be very useful. I'd like to heartily second that one. I tried every resource I could find to figure this out before I resorted to c.l.a. The example in Cohen's book is wrong, and he doesn't address its use in MI at all. The rationale just talks about it but doesn't put up any examples. I couldn't even find anything in the LRM that said this was legal after over an hour of searching. It'd be a shame if the only real documentation of this technique was word of mouth. -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Ted Dennison @ 1999-10-12 0:00 ` Stanley R. Allen 1999-10-13 0:00 ` Ted Dennison 1999-10-13 0:00 ` Vladimir Olensky 1999-10-14 0:00 ` Multiple Inheritance in Ada 95 [was Re: Self-referential types] Tucker Taft 2 siblings, 1 reply; 62+ messages in thread From: Stanley R. Allen @ 1999-10-12 0:00 UTC (permalink / raw) Ted Dennison wrote: > > The example in > Cohen's book is wrong, and he doesn't address its use in MI at all. For the record, Cohen is aware that the example on page 491 is in error and has noted so in his errata: http://www.research.ibm.com/people/n/ncohen/a3sl_errata.html -- Stanley Allen mailto:s_allen@hso.link.com ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Stanley R. Allen @ 1999-10-13 0:00 ` Ted Dennison 0 siblings, 0 replies; 62+ messages in thread From: Ted Dennison @ 1999-10-13 0:00 UTC (permalink / raw) In article <3803987F.2049ABFE@hso.link.com>, "Stanley R. Allen" <s_allen@hso.link.com> wrote: > Ted Dennison wrote: > > > > The example in > > Cohen's book is wrong, and he doesn't address its use in MI at all. > > For the record, Cohen is aware that the example on page 491 is > in error and has noted so in his errata: > > http://www.research.ibm.com/people/n/ncohen/a3sl_errata.html So he has. He gave a good explanation of why too. (sigh). -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Ted Dennison 1999-10-12 0:00 ` Stanley R. Allen @ 1999-10-13 0:00 ` Vladimir Olensky 1999-10-14 0:00 ` Multiple Inheritance in Ada 95 [was Re: Self-referential types] Tucker Taft 2 siblings, 0 replies; 62+ messages in thread From: Vladimir Olensky @ 1999-10-13 0:00 UTC (permalink / raw) Ted Dennison wrote in message <7tvq5g$28u$1@nnrp1.deja.com>... >In article <s06ji18vh1s47@corp.supernews.com>, > "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote: >> >> Matthew Heaney wrote in message <3802f2db_2@news1.prserv.net>... >> >This is the basis for programming with access discriminants, which is >> >how you do MI in Ada95. >> You might put a short article regarding this issue to Adapower. >> I am sure it will be very useful. > >I'd like to heartily second that one. I tried every resource I could >find to figure this out before I resorted to c.l.a. The example in >Cohen's book is wrong, and he doesn't address its use in MI at all. The >rationale just talks about it but doesn't put up any examples. I >couldn't even find anything in the LRM that said this was legal after >over an hour of searching. It'd be a shame if the only real >documentation of this technique was word of mouth. I think that the first part of it could explain why in Ada there is no SELF or THIS parameter ( which object instance can use to obtain reference to itself in other languages) and their equivalent constructs in Ada (and also what is similar and what is different in Ada and other languages regarding that issue). When this clear than other part may discuss more advanced topics such as MI implementation. Doing it this way may help people experienced in other languages or people beginning to learn Ada to grasp the idea without any additional strain. Comparison always help in introducing things that are not very familiar to others. Also if that is easy to understand then there would be less causes for some people to tell that Ada is too complicated/complex language that only military could like. Regards, Vladimir Olensky. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Multiple Inheritance in Ada 95 [was Re: Self-referential types] 1999-10-12 0:00 ` Ted Dennison 1999-10-12 0:00 ` Stanley R. Allen 1999-10-13 0:00 ` Vladimir Olensky @ 1999-10-14 0:00 ` Tucker Taft 2 siblings, 0 replies; 62+ messages in thread From: Tucker Taft @ 1999-10-14 0:00 UTC (permalink / raw) Ted Dennison wrote: > > In article <s06ji18vh1s47@corp.supernews.com>, > "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote: > > > > Matthew Heaney wrote in message <3802f2db_2@news1.prserv.net>... > > >This is the basis for programming with access discriminants, which is > > >how you do MI in Ada95. > > You might put a short article regarding this issue to Adapower. > > I am sure it will be very useful. > > I'd like to heartily second that one. I tried every resource I could > find to figure this out before I resorted to c.l.a. The example in > Cohen's book is wrong, and he doesn't address its use in MI at all. The > rationale just talks about it but doesn't put up any examples. I > couldn't even find anything in the LRM that said this was legal after > over an hour of searching. It'd be a shame if the only real > documentation of this technique was word of mouth. I have included a copy of a Language Study Note I wrote during the Ada 9X design process. It explains the was to support multiple-inheritance hierarchies using various Ada 95 features. Feel free to post this to AdaPower, etc. > > -- > T.E.D. > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA -------------------------------------------------------------------- !topic LSN on Multiple Inheritance in Ada 9X !key LSN-1033 on Multiple Inheritance in Ada 9X !reference MS-3.4.1;4.6 !reference MS-3.6.1;4.6 !reference MS-12.3.6;4.6 !from Tucker Taft $Date: 92/09/02 17:44:17 $ $Revision: 1.1 $ !discussion This Language Study Note discusses the creation of multiple inheritance type (semi-)lattices using the proposed Ada 9X object-oriented programming features. It is in part directed at programmers familiar with other object-oriented programming languages that build in syntax for a particular multiple-inheritance mechanism, rather than simply providing features needed to support it. In this discussion, we will in general use Ada 9X terminology, where every object has a single "type," and multiple similar types (typically in some kind of hierarchy or oligarchy) form a "class" of types. If we want to use the term "class" as it is used in C++ or Eiffel, we will always say "C++ class" or "Eiffel class." In some languages, such as Eiffel, multiple inheritance serves many purposes. For example, there is no equivalent in Eiffel to the "include" statement of C/C++ or the "with/use" clauses of Ada. Therefore, to gain direct visibility to the declarations of some other module, one must inherit from that module (Eiffel class). In C/C++, one can simply "include" file containing a set of type and object definitions. In Ada, one first identifies the external modules of interest via "with" clauses, and then chooses selectively whether to make only the name of the module (package) visible, or its contents (via a "use" clause). In both Eiffel and C++, one can choose to inherit from some other type, without making that visible to clients of the new type. Effectively, the linguistic multiple inheritance mechanism is being used to express not an "is a refinement of" relationship, but rather an "is implemented using" relationship. Finally, there are the situations where a single type visibly inherits from two or more other types. In these cases, this is rarely a symmetric situation. Rather, one of the ancestor types is the "primary" ancestor, while the others are typically "mix-ins" designed to augment behavior of the primary ancestor. Ada 9X supports multiple-inheritance module inclusion (via multiple "with"/"use" clauses), multiple-inheritance "is-implemented-using" via private extensions and record composition, and multiple-inheritance mix-ins via the use of generics, formal packages, and access discriminants. The Ada 9X mechanisms are designed to eliminate "distributed" overhead, so that there is no added expense for the general user of the language because of the presence of the mechanisms supporting multiple inheritance. There are basically three distinct situations associated with multi-inheritance mixins: 1) The case where the mix-in provides components and operations, and any overriding of these operations needs only to look at the components of the mix-in itself. 2) The case where the mix-in provides components and operations, and some of the overriding of these operations needs access to the whole object, rather than just the components of the mix-in. 3) Like (2), and in addition, any object with the mix-in must be able to be linked onto a list (or into some similar heterogeneous data structure) of other objects with the same mix-in. Case (1) is handled completely in Ada 9X by a record or private extension, with the type being mixed in (in a possibly extended form) as a component of the record extension. Case (2) is handled with a generic, that takes any type in a given class (formal derived type), adds components (via extension) and operations, and then reexports the extended type. The new operations have access to the whole object, not just to the components being added. Case (3) is handled with an access discriminant, that provides access to the enclosing object for the operations of the mix-in, while still allowing links through the mix-in. Generics can also be used to simplify the definition. Here are a few examples: Case (1) -- One has an abstract type "Set_of_Strings" and one wants to implement it by reusing an existing (concrete) type "Hash_Table": Here is the abstract type: type Set_Of_Strings is tagged limited private; type Element_Index is new Natural; -- Index within set. No_Element : constant Element_Index := 0; Invalid_Index : exception; procedure Enter( -- Enter an element into the set, return the index Set : in out Set_Of_Strings; S : String; Index : out Element_Index) is <>; procedure Remove( -- Remove an element from the set; ignore if not there Set : in out Set_Of_Strings; S : String) is <>; procedure Combine( -- Combine Additional_Set into Union_Set Union_Set : in out Set_Of_Strings; Additional_Set : Set_Of_Strings) is <>; procedure Intersect( -- Remove all elements of Removal_Set from Intersection_Set Intersection_Set : in out Set_Of_Strings; Removal_Set : Set_Of_Strings) is <>; function Size(Set : Set_Of_Strings) return Element_Index is <>; -- Return a count of the number of elements in the set function Index( -- Return the index of a given element; return No_Element if not there. Set : Set_Of_Strings; S : String) return Element_Index is <>; function Element(Index : Element_Index) return String is <>; -- Return element at given index position -- raise Invalid_Index if no element there. private type Set_Of_Strings is tagged limited ... Here is an implementation of this abstract type that inherits its interface from Set_Of_Strings, and its implementation from Hash_Table: type Hashed_Set(Table_Size : Positive) is new Set_Of_Strings with private; -- Now we give the specs of the operations being implemented procedure Enter( -- Enter an element into the set, return the index Set : in out Hashed_Set; S : String; Index : out Element_Index); procedure Remove( -- Remove an element from the set; ignore if not there Set : in out Hashed_Set; S : String); . . . etc. private type Hashed_Set(Table_Size : Positive) is new Set_Of_Strings with record Table : Hash_Table(1..Table_Size); end record; In the body of this package, we would provide the bodies for each of the operations, in terms of the operations available from Hash_Table. Chances are they don't match exactly, so a little bit of "glue" code will be necessary in any case. Case (2) -- One has a type Basic_Window that responds to various events and calls. One wants to embellish the Basic_Window in various ways with various mix-ins. type Basic_Window is tagged limited private; procedure Display(W : Basic_Window); procedure Mouse_Click(W : in out Basic_Window; Where : Mouse_Coords); . . . Now one can define any number of mix-in generics, like the following: generic type Some_Window is new Window with private; -- take in any descendant of Window package Label_Mixin is type Window_With_Label is new Some_Window with private; -- Jazz it up somehow. -- Overridden operations: procedure Display(W : Window_With_Label); -- New operations: procedure Set_Label(W : in out Window_With_Label; S : String); -- Set the label function Label(W : Window_With_Label) return String; -- Fetch the label private type Window_With_Label is new Some_Window with record Label : String_Quark := Null_Quark; -- An XWindows-Like unique ID for a string end record; In the generic body, we implement the Overridden and New operations as appropriate, using any inherited operations, if necessary. For example, this might be an implementation of the overridden Display: procedure Display(W : Window_With_Label) is begin Display(Some_Window(W)); -- First display the window normally, -- by passing the buck to the parent type. if W.Label /= Null_Quark then -- Now display the label if it is not null Display_On_Screen(XCoord(W), YCoord(W)-5, Value(W.Label)); -- Use two inherited functions on Basic_Window -- to get the coordinates where to display the label. end if; end Display; Presuming we have several such generic packages defined, We can now create the desired window by mixing in repeatedly. First we declare the tailored window as a private extension of Basic_Window, and then we define it via a sequence of instantiations: type My_Window is Basic_Window with private; . . . private package Add_Label is new Label_Mixin(Basic_Window); package Add_Border is new Border_Mixin(Add_Label.Window_With_Label); package Add_Menu_Bar is new Menu_Bar_Mixin(Add_Border.Window_With_Border); type My_Window is new Add_Menu_Bar.Window_With_Menu_Bar with null; -- Final window is a null extension of Window_With_Menu_Bar. -- We could instead make a record extension and -- add components for My_Window over and above those -- needed by the mix-ins. Case(3) -- In this case, let us presume we have two independent hierarchies, one for Windows, which represent areas on the screen, and one for Monitors, which wait for an object to change, and then do something in reaction to it. An object that supports Monitors keeps a linked list of Monitors, and calls their Update operation whenever the object is changed. For example: type Monitor; type Monitor_Ptr is access Monitor'CLASS; type Monitored_Object is tagged limited -- Monitored objects are derived from this root type record First : Monitor_Ptr; - List of monitors -- More components to be added by extension end record; type Monitored_Object_Ptr is access Monitored_Object'CLASS; type Monitor is tagged limited record Next : Monitor_Ptr; Obj : Monitored_Object_Ptr; -- More components to be added by extension end record; procedure Update(M : in out Monitor) is <>; -- Dispatching operation, called when monitored object -- is changed. Now suppose we want to create a Window that can act as a Monitor as well as a Window: First we define a mix-in that is a monitor, and override its Update op: type Monitor_Mixin(Win : access Basic_Window'CLASS) is new Monitor with null; procedure Update(M : in out Monitor_Mixin); The body for this Update could be: procedure Update(M : in out Monitor_Mixin) is -- On an Update, simply re-Display the window begin Display(M.Win); -- This is a dispatching call end Update; Now we can "mix" this Monitor_Mixin into any window type, as follows: type Window_That_Monitors is new My_Window with record Mon : Monitor_Mixin(Window_That_Monitors'ACCESS); end record; We could define a tailored Monitor mix-in that did something besides just call the Display operation of the associated Window. But in many cases, this simple one will do the job. ----------------------------- As these examples illustrate, Ada 9X provides support for the construction of essentially arbitrary multiple inheritance type lattices, without having to commit itself to a single linguistic mechanism for multiple inheritance, and without burdening simple single-inheritance problems with the complexity and implementation burden of linguistic multiple inheritance. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` news.oxy.com 1999-10-12 0:00 ` Ted Dennison @ 1999-10-12 0:00 ` Matthew Heaney 1 sibling, 0 replies; 62+ messages in thread From: Matthew Heaney @ 1999-10-12 0:00 UTC (permalink / raw) In article <s06ji18vh1s47@corp.supernews.com> , "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote: > As for me I never used such thing and was not sure that it makes any sense > to apply access attrubute to anything except oject instance. It *is* an object instance. The expression T'Access, inside the declaration of a type, refers to the "current instance," which is of course an object. > In other languages there exists "Self" parameter and when it is used in > class declarations it refers to current class instance. Same thing, different syntax. > You might put a short article regarding this issue to Adapower. > I am sure it will be very useful. My plan is to put an article in the Design Patterns archive; David will cross-post at AdaPower. Matt -- Creationists attempt to draw a line between evolutionary biology and the rest of science by remarking that large-scale evolution cannot be observed. This tactic fails. Large-scale evolution is no more inaccessible to observation than nuclear reactions or the molecular composition of water. Abusing Science: The Case Against Creationism Philip Kitcher ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Matthew Heaney 1999-10-12 0:00 ` Richard D Riehle 1999-10-12 0:00 ` news.oxy.com @ 1999-10-12 0:00 ` Ted Dennison 1999-10-12 0:00 ` Matthew Heaney 1999-10-12 0:00 ` Robert I. Eachus 3 siblings, 1 reply; 62+ messages in thread From: Ted Dennison @ 1999-10-12 0:00 UTC (permalink / raw) In article <3802f2db_2@news1.prserv.net>, "Matthew Heaney" <matthew_heaney@acm.org> wrote: > This is the basis for programming with access discriminants, which is > how you do MI in Ada95. Is there somewhere I can go to see an example of this kind of MI? The Rationale says pretty much the same thing, but Cohen's tome doesn't go over it at all. -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Ted Dennison @ 1999-10-12 0:00 ` Matthew Heaney 0 siblings, 0 replies; 62+ messages in thread From: Matthew Heaney @ 1999-10-12 0:00 UTC (permalink / raw) In article <7tvjav$se6$1@nnrp1.deja.com> , Ted Dennison <dennison@telepath.com> wrote: >> This is the basis for programming with access discriminants, which is >> how you do MI in Ada95. > > Is there somewhere I can go to see an example of this kind of MI? The > Rationale says pretty much the same thing, but Cohen's tome doesn't go > over it at all. You can read my posts in the Ada95 design patterns archive. The observer and mediator patterns feature the access discriminant technique. (Last month (sep 99) I did a whole series on observer variations.) <http://www.acm.org/archives/patterns.html> Let me know if you have trouble finding or understanding the material. I also recently wrote Indexed_IO (B tree) and Indexed_Sequential_IO (B+ tree) packages. The File_Type is implemented using the Rosen Trick, which uses self-reference to get a variable view of an otherwise constant object. <http://www.adapower.com/reuse/indexed_io.html> Matt -- If we let the Creationists have their way, we may as well go whole hog. Let us reintroduce the flat-earth theory, the chemistry of the four elements, and mediaeval astrology. For these outworn doctrines have just as much claim to rival current scientific views as Creationism does to challenge evolutionary biology. Abusing Science: The Case Against Creationism Philip Kitcher ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Matthew Heaney ` (2 preceding siblings ...) 1999-10-12 0:00 ` Ted Dennison @ 1999-10-12 0:00 ` Robert I. Eachus 1999-10-12 0:00 ` Matthew Heaney 3 siblings, 1 reply; 62+ messages in thread From: Robert I. Eachus @ 1999-10-12 0:00 UTC (permalink / raw) Matthew Heaney wrote: > For a limited type T, then inside the declaration of the type, the > expression T'Access refers to the "current instance" of the type. > > This is something a lot of programmers haven't learned yet. > > This is the basis for programming with access discriminants, which is > how you do MI in Ada95. I have to butt in here. It may be how you do MI in Ada, and it is one way, but I find it ugly. If you treat a private access type as the object, then you have to do a bit more work inside the package, but the exterior looks much cleaner, and the users don't have to use 'Access at all. (Often you don't need it inside the package either.) The linked list example becomes: generic type Element is private; --or limited private package Lists is type List is private; procedure Append(L: in out List; E: in Element); procedure Prepend(L: in out List; E: in Element); procedure Pop(L: in out List; E: out Element); function Is_Empty(L: List) return Boolean; function First(L: List) return Element; function Last(L: List) return Element; -- etc private type Real_List_Element; type List is access all List; type Real_List_Element is record E: Element; -- if Element is limited private, you need to declare another access -- type and use it here. Next, Previous: List; end record; end Lists; -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Robert I. Eachus @ 1999-10-12 0:00 ` Matthew Heaney 1999-10-13 0:00 ` Ted Dennison ` (2 more replies) 0 siblings, 3 replies; 62+ messages in thread From: Matthew Heaney @ 1999-10-12 0:00 UTC (permalink / raw) In article <3803B5E3.F96A6DD4@mitre.org> , "Robert I. Eachus" <eachus@mitre.org> wrote: >> This is the basis for programming with access discriminants, which is >> how you do MI in Ada95. > > I have to butt in here. It may be how you do MI in Ada, and it is > one way, but I find it ugly. If you treat a private access type as the > object, then you have to do a bit more work inside the package, but the > exterior looks much cleaner, and the users don't have to use 'Access at > all. (Often you don't need it inside the package either.) I think we're in agreement. I use access discriminants (indeed, taggedness) strictly as an implementation technique. As much as possible you want to push the type composition infrastructure into the private part of the spec. For example, most of my observer types only privately derive from Observer_Type; the public part is just "limited private." with Clock_Timers; package Digital_Clocks is type Digital_Clock (Timer : access Clock_Timer'Class) is limited private; private type Control_Type (Clock : access Digital_Clock) is new Limited_Controlled with null record; type Digital_Clock (Timer : access Clock_Timer'Class) is new Observer_Type (Timer) with record Control : Control_Type (Digital_Clock'Access); --!!! end record; end Digital_Clocks; Here, Digital_Clock "multiply inherits" from two different parent types. All the machinery is hidden in the private region, exactly where it belongs. I do one better when I observe two subjects simultaneously: with Master_Timers; with Slave_Timers; package Digital_Clocks is type Digital_Clock (Master : access Master_Timer; Slave : access Slave_Timer) is limited private; private type Master_Obs_Type (Clock : access Digital_Clock) is new Observer_Type with null record; type Slave_Obs_Type (Clock : access Digital_Clock) is new Observer_Type with null record; type Control_Type (Clock : access Digital_Clock) is new Limited_Controlled with null record; type Digital_Clock (...) is limited record Master_Obs : Master_Obs_Type (Digital_Clock'Access); Slave_Obs : Slave_Obs_Type (Digital_Clock'Access); Control : Control_Type (Digital_Clock'Access); end record; end Digital_Clocks; Here, Digital_Clock "multiply inherits" from three different parent types. But all the machinery is hidden in the private region, exactly where it should be. In recent article I showed how to observe individual attributes of a subject, as compared to observing the subject itself. If you declare the observer types as children of the subject, then you can even hide the fact that the subject derives from Subject_Type. Some guys use public taggedness everywhere with gay abandon. This is wrong. Don't use taggedness unless you need to, and if you do, then hide it in the private region if you can. Under no circumstances should you have deep inheritance hierarchies. Make hierarchies broad and shallow; say, an abstract parent type and a non-abstract sibling derivations. (This is the approach I use over and over again in my articles in the Design Patterns archive.) I realize this is not the OO approach of other languages, but the benefits are that you have far less coupling. These examples (and many more) can all be found in the design patterns archive. <http://www.acm.org/archives/patterns.html> I will be discussing this technique this Sunday (17 Oct 99) during my Design Patterns tutorial, at this year's SIGAda conference. Matt -- The political forces that try to eliminate evolution from science classrooms impose a narrow, sectarian doctrine on our educational systems. This imposition represents an affront not only to the constitutional separation of church and state but also to the moral and intellectual integrity embedded in that constitution. <http://www.nabt.org/evolutionks.html> ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Matthew Heaney @ 1999-10-13 0:00 ` Ted Dennison 1999-10-13 0:00 ` Matthew Heaney 1999-10-13 0:00 ` Vladimir Olensky 1999-10-13 0:00 ` Robert I. Eachus 2 siblings, 1 reply; 62+ messages in thread From: Ted Dennison @ 1999-10-13 0:00 UTC (permalink / raw) In article <3803c8bc_2@news1.prserv.net>, "Matthew Heaney" <matthew_heaney@acm.org> wrote: > In article <3803B5E3.F96A6DD4@mitre.org> , "Robert I. Eachus" > <eachus@mitre.org> wrote: > > type Digital_Clock (...) is > limited record > Master_Obs : Master_Obs_Type (Digital_Clock'Access); > Slave_Obs : Slave_Obs_Type (Digital_Clock'Access); > Control : Control_Type (Digital_Clock'Access); > end record; Ok...What does this buy you over using non-anonomous access fields and an initilization? And how does this constitute MI? > Some guys use public taggedness everywhere with gay abandon. This is > wrong. Don't use taggedness unless you need to, and if you do, then > hide it in the private region if you can. Hmm. Generally I do that so that someone who wants to extend a new type that I haven't thought of doesn't have to put it in a child package. But admittedly, I don't myself derive new types without putting them in child packages. So perhaps I'm allowing too much freedom? > I will be discussing this technique this Sunday (17 Oct 99) during my > Design Patterns tutorial, at this year's SIGAda conference. Hmmm. It would be nice to attend that. But I don't think I could sell enough candy bars at work in the next couple of days to pay for the trip. :-) -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-13 0:00 ` Ted Dennison @ 1999-10-13 0:00 ` Matthew Heaney 0 siblings, 0 replies; 62+ messages in thread From: Matthew Heaney @ 1999-10-13 0:00 UTC (permalink / raw) In article <7u25pu$p4k$1@nnrp1.deja.com> , Ted Dennison <dennison@telepath.com> wrote: >> type Digital_Clock (...) is >> limited record >> Master_Obs : Master_Obs_Type (Digital_Clock'Access); >> Slave_Obs : Slave_Obs_Type (Digital_Clock'Access); >> Control : Control_Type (Digital_Clock'Access); >> end record; > > Ok...What does this buy you over using non-anonomous access fields and > an initilization? And how does this constitute MI? Because the observer types have a primitive operation (Update) called by their subject. The Master_Timer subject calls back the Master_Obs component of the Digital_Clock, and the Slave_Timer subject calls back the Slave_Obs component. See the article about multiple subjects in the design patterns archive, from whence this was paraphrased. Perhaps it would have been more obvious to have done it this way: type Digital_Clock (...) is new Limited_Controlled with record Master_Obs : Master_Obs_Type (Digital_Clock'Access); Slave_Obs : Slave_Obs_Type (Digital_Clock'Access); end record; Syntactically, Digital_Clock has only a single parent, Limited_Controlled. But logically, it has three parents (Limited_Controlled once, and Observer_Type twice). Matt -- The theory of evolution is quite rightly called the greatest unifying theory in biology. The diversity of organisms, similarities and differences between kinds of organisms, patterns of distribution and behavior, adaptation and interaction, all this was merely a bewildering chaos of facts until given meaning by the evolutionary theory. Populations, Species, and Evolution Ernst Mayr ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Matthew Heaney 1999-10-13 0:00 ` Ted Dennison @ 1999-10-13 0:00 ` Vladimir Olensky 1999-10-13 0:00 ` Vladimir Olensky 1999-10-18 0:00 ` Robert Dewar 1999-10-13 0:00 ` Robert I. Eachus 2 siblings, 2 replies; 62+ messages in thread From: Vladimir Olensky @ 1999-10-13 0:00 UTC (permalink / raw) Matthew Heaney wrote in message <3803c8bc_2@news1.prserv.net>... >In article <3803B5E3.F96A6DD4@mitre.org> , "Robert I. Eachus" ><eachus@mitre.org> wrote: >I will be discussing this technique this Sunday (17 Oct 99) during my >Design Patterns tutorial, at this year's SIGAda conference. By the way are you going to make it available online or available for download (e.g. on Adapower tutorials page). It would be very valuable. I found that proceedings and materials of almost all conferences are usually neither available online nor for download. I think this is extremely bad. By such a lot of valuable information just lost. Only participants have it. I think that in case of Ada all proceedings and materials should be freely available online and for download. I think that this is one of the ways to promote Ada. If this work need sponsors I hope that Ada Resource Association could be such and moreover it could even sponsor the work to make most valuable Ada books available online (including setting up agreements with publishers and authors). This could be real investment in Ada. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-13 0:00 ` Vladimir Olensky @ 1999-10-13 0:00 ` Vladimir Olensky 1999-10-18 0:00 ` Robert Dewar 1 sibling, 0 replies; 62+ messages in thread From: Vladimir Olensky @ 1999-10-13 0:00 UTC (permalink / raw) Vladimir Olensky wrote in message ... > I found that proceedings and materials of almost all conferences >are usually neither available online nor for download. As a matter of fact some time ago I was trying to get some interesting reports of one of the conferences (I do not remember now it's exact name) that was held in Europe but found that I should pay to local Verlag distributor (which does not exist at my location) to obtain them. I was very disappointed. Here I should mention that SigAda (former Tri-Ada) papers are available at www.AdaIC.org. For some reason there is no materials for 1997. But there is no other direct references from "Reports & Papers" page to proceedings (available online) of other conferences where Ada related report were presented. There were others that were held not only in US but in Europe also. May be I was not trying too hard to find them ? But I do not think it should hard. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-13 0:00 ` Vladimir Olensky 1999-10-13 0:00 ` Vladimir Olensky @ 1999-10-18 0:00 ` Robert Dewar 1999-10-18 0:00 ` Vladimir Olensky 1999-10-18 0:00 ` Laurent Guerby 1 sibling, 2 replies; 62+ messages in thread From: Robert Dewar @ 1999-10-18 0:00 UTC (permalink / raw) In article <s08h609obhk23@corp.supernews.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > I think this is extremely bad. By such a lot of valuable > information just lost. > Only participants have it. There is the amazing facility known as a library (I guess the online crowd have forgotten about these amazing institutions :-) > I think that in case of Ada all proceedings and materials > should be > freely available online and for download. When authors create works, including conference presentations, they are copyrighted. It is up to the presenters and organizers of conferences to decide how available to make the materials. Consumers always prefer complete availability, producers are not always willing to comply :-) I am sure that if you ask the typical net surfer whether XXX should be freely available online, the answer will be yes for almost all possible XXX. It is sort of like asking people if they would like it better if stores would stop charging money for their merchandise ... The dynamics here is quite tricky. Even getting the ISO standard semi-available was a huge effort. Most owners of copyrights are very nervous about net availability, and are also nervous about the kind of sentiment expressed here (everything should automatically be made available free). Remember that, following the commerce clause of the constitution, the purpose of copyright is to encourage creation. It's hard already to get publishers to risk doing Ada books, if you insist they all be on line, then one possible outcome is that they will all be on line, all zero of them, so you have to work for a balance here. > I think that this is one of the ways to promote Ada. > If this work need sponsors I hope that Ada Resource > Association could be such and moreover it could even sponsor > the work to make > most valuable Ada books available online (including setting up agreements > with publishers and authors). Ahem .. this is not just a matter of "work .. [to] .. setting up agreements", there is $$$ involved. Why would a publisher publish a book, if anyone can download it free? Well there are legitimate answers to this and a few publishers have been convinced to publish electronic books, or allow their hard copy books to be available on line, but this is an exception. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-18 0:00 ` Robert Dewar @ 1999-10-18 0:00 ` Vladimir Olensky 1999-10-18 0:00 ` Laurent Guerby 1 sibling, 0 replies; 62+ messages in thread From: Vladimir Olensky @ 1999-10-18 0:00 UTC (permalink / raw) Robert Dewar wrote in message <7uds5f$ljp$1@nnrp1.deja.com>... >In article <s08h609obhk23@corp.supernews.com>, > "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: > >> I think this is extremely bad. By such a lot of valuable >> information just lost. >> Only participants have it. > >There is the amazing facility known as a library (I guess the >online crowd have forgotten about these amazing institutions :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I do not think so. This is more general issue. Availability of printed information in a library depends on where this library is located (country, location etc.). I am sure that the library of NY university and many other universities in some countries have a lot of the printed materials. A lot of libraries in many countries do not have many of the published materials. It is just imposible to have all in an average labrary. This is also a matter of $$$. This vary from country to country and in some of them in order to get some material you should order that material and wait several weeks or monthes. After that one gets it for limited period of time. In some countries one should be either student or proffesor to get access to the university labraries. Just weight all the efforts for getting needed information and it will be clear why now Internet plays such great role in education (obtaining needed information). If the materil is available online one can save a lot of time and efforts. There are some other issues here that also has significant impact on that. In many cases online internet access is the only alternative. One can (almost) instantly obtains what is needed. Internet now has great positive impact on the progress and will have much more in the future. >> I think that in case of Ada all proceedings and materials >> should be >> freely available online and for download. <snipped> >> I think that this is one of the ways to promote Ada. >> If this work need sponsors I hope that Ada Resource >> Association could be such and moreover it could even sponsor >> the work to make >> most valuable Ada books available online (including setting up >agreements >> with publishers and authors). > >Ahem .. this is not just a matter of "work .. [to] .. setting >up agreements", there is $$$ involved. Why would a publisher >publish a book, if anyone can download it free? Well there are >legitimate answers to this and a few publishers have been >convinced to publish electronic books, or allow their hard >copy books to be available on line, but this is an exception. When I said to "sponsor" I hoped that this would mean to spend some $$$. I had the understanding that this is one of the goals of the Ada Resource Association to promote Ada. To promote something one need to spend some money for that in a right way. (Java promotion is a good example of that). I just wonder if Ada Resource Association has some $$$ to sponsor and promote Ada in a way described above ? Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-18 0:00 ` Robert Dewar 1999-10-18 0:00 ` Vladimir Olensky @ 1999-10-18 0:00 ` Laurent Guerby 1 sibling, 0 replies; 62+ messages in thread From: Laurent Guerby @ 1999-10-18 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > [...] > Remember that, following the commerce clause of the > constitution, the purpose of copyright is to encourage > creation. It's hard already to get publishers to risk > doing Ada books, if you insist they all be on line, then > one possible outcome is that they will all be on line, > all zero of them, so you have to work for a balance here. > [...] The Ada case is a bit special, since 2 Ada books come from work that were available for free on the net: the book from the "Lovelace" tutorial and "Ada for C/C++ programmers" which started as a web page. Also an argument to consider is that if everyone was using copyright to get the "monopoly" (okay, not the right term) of having something available on a printed book, there would be no web page and no web at all! All the information available for free on the web is a proof that copyright-protected and sold-for-money books are not strictly necessary to encourage creation. However as you said, there is a balance to be found there, see Tim O'Reilly opinions on book publishing on the matter for example. --LG ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Matthew Heaney 1999-10-13 0:00 ` Ted Dennison 1999-10-13 0:00 ` Vladimir Olensky @ 1999-10-13 0:00 ` Robert I. Eachus 1999-10-13 0:00 ` Brian Rogoff 2 siblings, 1 reply; 62+ messages in thread From: Robert I. Eachus @ 1999-10-13 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > In article <3803B5E3.F96A6DD4@mitre.org> , Iwrote: > > I have to butt in here. It may be how you do MI in Ada, and it is > > one way, but I find it ugly. If you treat a private access type as the > > object, then you have to do a bit more work inside the package, but the > > exterior looks much cleaner, and the users don't have to use 'Access at > > all. (Often you don't need it inside the package either.) > > I think we're in agreement. I'm not sure we are, since I was addressing a slightly different point. You pass access parameters in cases where I pass a private access type to eliminate any visible (to the user of the abstraction) use of 'Access. If you need to make subclassing visible, you end up making the use of access parameters necessary, but I believe that public subclassing is a bad thing, and that most visible subclassing should be done using generic packages to do mix-ins. I wasn't really criticizing your approach, just pointing out that Ada supports two different idioms in this area. > Under no circumstances should you have deep inheritance hierarchies. > Make hierarchies broad and shallow; say, an abstract parent type and a > non-abstract sibling derivations. (This is the approach I use over and > over again in my articles in the Design Patterns archive.) Amen! Even when I have lots of generic mixins in the private part, the Ada idiom seems to be that there are three types of classes: abstract root classes, intermediate (again abstract) subclasses when doing mixins, and the (non-abstract) visible classes that actually have objects associated with them. In Ada is is almost always a bug to have a non-abstract parent of a class. > I realize this is not the OO approach of other languages, but the > benefits are that you have far less coupling. Amen again. Have you ever read "Nesting in Ada is for the Birds" by Lori Clarke, and others? It was written before Ada 83 was finalized, and discussed the same beneficial effect on coupling when you removed nesting of procedures. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-13 0:00 ` Robert I. Eachus @ 1999-10-13 0:00 ` Brian Rogoff 1999-10-15 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 62+ messages in thread From: Brian Rogoff @ 1999-10-13 0:00 UTC (permalink / raw) On Wed, 13 Oct 1999, Robert I. Eachus wrote: > Amen again. Have you ever read "Nesting in Ada is for the Birds" by > Lori Clarke, and others? It was written before Ada 83 was finalized, > and discussed the same beneficial effect on coupling when you removed > nesting of procedures. Does it discuss the detrimental effect on lots of other aspects of Ada when you remove nesting of procedures? -- Brian ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-13 0:00 ` Brian Rogoff @ 1999-10-15 0:00 ` Robert I. Eachus 1999-10-15 0:00 ` Marin David Condic ` (3 more replies) 0 siblings, 4 replies; 62+ messages in thread From: Robert I. Eachus @ 1999-10-15 0:00 UTC (permalink / raw) Brian Rogoff wrote: > Does it discuss the detrimental effect on lots of other aspects of Ada > when you remove nesting of procedures? Okay, I'll bite what are they? Note that nesting of procedures refers to procedures declared inside other procedures, not procedures called inside other procedures, or within packages. AFIAK, it is almost always poor engineering to declare procedures within other procedures in Ada. The chief exception is recursive descent parsers, and even in that case there are good arguments for using unnested procedures. Also there are cases where you want to break a procedure into subunits for implementation reasons: procedure A (Some: Parameters) is Some_Local: Variables; procedure Start is separate; -- Ed will write procedure Do_It is separate; -- Joe is doing this procedure Cleanup is separate; -- Ed again begin Start; Do_It; Cleanup; end A; Often though, those separates disappear before the code is entered into the CM system. Ada lets fold called once procedures back in as declare blocks with no change in semantic interpretation. Note also that I am talking about procedures. Many (nested)functions in Ada would be implemented in other languages as macros. Using such inlined functions is good programming practice in Ada. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-15 0:00 ` Robert I. Eachus @ 1999-10-15 0:00 ` Marin David Condic 1999-10-15 0:00 ` Robert I. Eachus 1999-10-18 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 1 reply; 62+ messages in thread From: Marin David Condic @ 1999-10-15 0:00 UTC (permalink / raw) "Robert I. Eachus" wrote: > AFIAK, it is almost always poor engineering to declare procedures > within other procedures in Ada. The chief exception is recursive descent > parsers, and even in that case there are good arguments for using > unnested procedures. Also there are cases where you want to break a > procedure into subunits for implementation reasons: > This debate has been around before and a case has been made on the other side. Similar to the Cobol "perform", nested procedures give you a way of grouping blobs of code under some sort of descriptive name which helps clarify the main body of the code - especially where the main body of the code might otherwise become too deeply nested in control sturctures. For example: procedure Process_Payroll is procedure Read_In_Transaction_Trapping_Device_Errors ( Trans : out Trans_Type) is begin --Use Your Imagination end Read_In_Transaction_Trapping_Device_Errors ; function Transaction_Successfully_Read return Boolean is begin --More of the same... end Transaction_Successfully_Read ; procedure Edit_Transaction_For_Keypunch_Errors ( Trans : in out Trans_Type) is begin --Fill in the blanks. end Edit_Transaction_For_Keypunch_Errors ; begin --blahblahblah while (not End_Of_File (Trans_File)) loop Read_In_Transaction_Trapping_Device_Errors (Trans) ; if (Transaction_Successfully_Read) then Edit_Transaction_For_Keypunch_Errors (Trans) ; end if ; --yadayadayada end loop ; --blahblahblah end Process_Payroll ; You can always export the nested procedures by making them "is separate" or just stand-alone procedures brought in with a "with" clause, but if the code volume is not too large and the access to common data is high, I'd prefer to see it local to the same file from which it is called. I wouldn't think of that as bad software engineering or bad style. It all depends on if it is helping you clarify what you are doing and is not being badly overused. Obviously, after "a certain size" you probably want these things in separate units for configuration management, reusability and other concerns. What is the threshold? I'd say "As many lines as you can read while holding your breath." :-) MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-15 0:00 ` Marin David Condic @ 1999-10-15 0:00 ` Robert I. Eachus 1999-10-18 0:00 ` Robert Dewar 0 siblings, 1 reply; 62+ messages in thread From: Robert I. Eachus @ 1999-10-15 0:00 UTC (permalink / raw) Marin David Condic wrote: > This debate has been around before and a case has been made on the other > side. Similar to the Cobol "perform", nested procedures give you a way of > grouping blobs of code under some sort of descriptive name which helps > clarify the main body of the code - especially where the main body of the > code might otherwise become too deeply nested in control sturctures. But this is the wrong way to do that in Ada. There are two similar cases and several structurally different ways to organize them. First if there is no shared local data common to all of the subprograms, or if tasking is not an issue, you can put the local data in a package body. The package exports the subprograms, and the driver just contains a few calls and perhaps some logic: package Payroll is procedure Read_In_Transaction_Trapping_Device_Errors ( Trans : out Trans_Type); function Transaction_Successfully_Read return Boolean; procedure Edit_Transaction_For_Keypunch_Errors ( Trans : in out Trans_Type); end package Payroll; with Payroll; use Payroll; procedure Process_Payroll is begin --blahblahblah while (not End_Of_File (Trans_File)) loop Read_In_Transaction_Trapping_Device_Errors (Trans) ; if (Transaction_Successfully_Read) then Edit_Transaction_For_Keypunch_Errors (Trans) ; end if ; --yadayadayada end loop ; --blahblahblah end Process_Payroll ; Why is this better? Because it promotes reuse. Other payroll operations can be created which share some, but not all, of the subroutines used by Process_Payroll. The other case, of course, is where you have many payroll objects and need local data for each, whether or not tasking is involved. You can either create payroll objects and store the local data as part of their state, create a task type to represent the instances, or (usually best) create an instance of a generic package for each payroll. The instantiation of this package may be internal to Process_Payroll, or Process_Payroll can be just another declaration in that package. But in any case, the "right" place to keep state in Ada is almost always in packages or tasks, not subprogram bodies. I'll tell you a (now oft-told) story about this. At Honeywell we implemented an in house cross-compiler from Multics to the DPS-6 series. During the implementation, we had no idea whether the best way to find uplevel references in the stack would be via static links or a display. Multics being Multics, we put a counter in the compiler, with a feature to squirrel away the source whenever an uplevel reference was encountered. It also sent mail to the Ada compiler group every morning if it trapped a reference. (The compiler was installed on several Multics machines, but they were all connected to the ARPAnet.) Oh, the compiler also did a full call tree trace to allow the code generator to combine the stack frame of a nested procedure with its parent if the compiler could determine that there were no recursive calls, and no stack objects whose size depended on the parameters to the inner procedure. I finally set the trap off two and half years later, while we were running the ACVC tests. Needless to say, we implemented neither static links or a display, and just left in the code (in the run time) which walked down the call stack until it found the statically containing frame. Potentially very slow if there was an uplevel reference, but as we had shown, wasting even one clock per stack frame created would have been slower on the average. (Note that the 'dynamic' walk was needed for exceptions in any case.) As a result, not only that compiler, but most Ada compilers, are tailored to the expected feature usage. Anyone who violates those assumptions will be penalized by slow code. (Another example is exceptions, in Ada the compiler author will try to lower the cost of creating exception handler scopes at the cost of extra overhead when an exception occurs. Therefore, you are much better off checking in the code for conditions that are not all that rare.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-15 0:00 ` Robert I. Eachus @ 1999-10-18 0:00 ` Robert Dewar 1999-10-19 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 62+ messages in thread From: Robert Dewar @ 1999-10-18 0:00 UTC (permalink / raw) In article <38079D6F.4F7C00FA@mitre.org>, "Robert I. Eachus" <eachus@mitre.org> wrote: > But this is the wrong way to do that in Ada. There are two similar > cases and several structurally different ways to organize them. First > if there is no shared local data common to all of the subprograms, or if > tasking is not an issue, you can put the local data in a ^^^^^^^^^^^^^^^^^^^^^^^ Ah ha! There it is. The trouble is that the creator may not think tasking is an issue, but later on a consumer is interested in task safety. PLEASE PLEASE default your thinking to assume that tasking *is* an issue, and make thinks task safe by default. Only introduce (well documented!) thread non-safety deliberately if there is a VERY good reason for it. package body. > The package exports the subprograms, and the driver just contains a few > calls and perhaps some logic: Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-18 0:00 ` Robert Dewar @ 1999-10-19 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 62+ messages in thread From: Robert I. Eachus @ 1999-10-19 0:00 UTC (permalink / raw) Robert Dewar wrote: > Ah ha! There it is. The trouble is that the creator may not > think tasking is an issue, but later on a consumer is interested > in task safety. PLEASE PLEASE default your thinking to assume > that tasking *is* an issue, and make thinks task safe by > default. Only introduce (well documented!) thread non-safety > deliberately if there is a VERY good reason for it. Sorry, that was an aside that could be misleading. I was referring to a different issue: The cases where the outer procedure creates one or more tasks. These cases are somewhat harder to deal with because of the rules about masters and when a scope is left. For instance if you move a task out of a procedure, so its entries are visible to other (formerly nested) procedures, then you may have to add explicit code to terminate the tasks at the right point in time. This is why you may want to instantiate a generic package inside the procedure to get the right semantics without kludges. In the cases Robert Dewar is talking about, where tasking is not dealt with in otherwise sharable code, you can often factor the tasking out at a higher level. I often wrap procedures this way: procedure Protected_Foo is begin Lock.Seize ; Foo; Lock.Release; end; -- add parmeters to taste. This provides both tasking and non-tasking safe versions. It will work correctly even if Foo is recursive. The other way to deal with potential tasking is to pass all shared data in one or more explicit parameters. This way the caller can do anything necessary at his level. The random number packages in Ada are a result of this type of thinking. Since they pass a generator object around, it is up to the user in a tasking environment to decide which tasks should share generators and how. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-15 0:00 ` Robert I. Eachus 1999-10-15 0:00 ` Marin David Condic @ 1999-10-18 0:00 ` Robert Dewar 1999-10-18 0:00 ` Brian Rogoff 1999-10-18 0:00 ` Ed Falis [not found] ` <7u86su$o5v$1@nntp8.atl.mindspring.net> [not found] ` <slrn80fl9f.68j.aidan@skinner.demon.co.uk> 3 siblings, 2 replies; 62+ messages in thread From: Robert Dewar @ 1999-10-18 0:00 UTC (permalink / raw) In article <38077EB3.E6911567@mitre.org>, "Robert I. Eachus" <eachus@mitre.org> wrote: > Brian Rogoff wrote: > > AFIAK, it is almost always poor engineering to declare procedures > within other procedures in Ada. The chief exception is recursive descent > parsers. What an *amazing* statement. I am completely flabbergasted! First, I don't see recursive descent parsers as being relevant here, and see no reason for nesting there. There are however MANY MANY examples where nesting makes excellent sense, and IMO any language that does not permit nested procedures is badly broken, There are zillions of reasons for nesting, but let me just give two. 1. Localization of names. If you have a small procedure that is just called a couple of times within a single procedure, it is FAR better to restrict its name space by nesting it within the calling procedure, and it is indeed very bad style to unnest it in this case. One particular case is where you have a recursive implementation of a non recursive procedure interface for the client, often referencing one of the parameters of the outer procedure non-locally. 2. Nested procedures makes it FAR easier to make things thread safe, because you can have variables that are "global" to a set of cooperating procedures, but are still on a local thread-specific stack of the enclosing procedurers. In a language without nested procedures, you often see real global variables used for this purpose, which is a common source of non-thread safeness. Yes, you can take the position that you should never have any non-local references, but this often obfuscates the code and is error prone. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-18 0:00 ` Robert Dewar @ 1999-10-18 0:00 ` Brian Rogoff 1999-10-18 0:00 ` Ed Falis 1 sibling, 0 replies; 62+ messages in thread From: Brian Rogoff @ 1999-10-18 0:00 UTC (permalink / raw) On Mon, 18 Oct 1999, Robert Dewar wrote: > In article <38077EB3.E6911567@mitre.org>, > "Robert I. Eachus" <eachus@mitre.org> wrote: > > AFIAK, it is almost always poor engineering to declare > procedures > > within other procedures in Ada. The chief exception is > recursive descent > > parsers. > > What an *amazing* statement. I am completely flabbergasted! > > First, I don't see recursive descent parsers as being > relevant here, and see no reason for nesting there. The argument I hear is that by nesting the inner parsing routines have no arguments, FWIW. Also, when writing backtracking recursive descent parsers (OK, I've only done it once in Ada :-) the solution with procedure nesting and procedure parameters (faked with generics in Ada) seems fairly understandable to me. > There are however MANY MANY examples where nesting makes > excellent sense, and IMO any language that does not permit > nested procedures is badly broken, I agree, but IMO the readability argument, perhaps subsuming your arguments, is important enough that all other considerations are secondary. I find this true even in "sequential" Ada. -- Brian > > There are zillions of reasons for nesting, but let me just > give two. > > 1. Localization of names. If you have a small procedure that > is just called a couple of times within a single procedure, > it is FAR better to restrict its name space by nesting it > within the calling procedure, and it is indeed very bad > style to unnest it in this case. One particular case is > where you have a recursive implementation of a non recursive > procedure interface for the client, often referencing one > of the parameters of the outer procedure non-locally. > > 2. Nested procedures makes it FAR easier to make things thread > safe, because you can have variables that are "global" to a set > of cooperating procedures, but are still on a local > thread-specific stack of the enclosing procedurers. > In a language without nested procedures, you often see real > global variables used for this purpose, which is a common > source of non-thread safeness. Yes, you can take the position > that you should never have any non-local references, but this > often obfuscates the code and is error prone. > > > Sent via Deja.com http://www.deja.com/ > Before you buy. > > ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-18 0:00 ` Robert Dewar 1999-10-18 0:00 ` Brian Rogoff @ 1999-10-18 0:00 ` Ed Falis 1999-10-19 0:00 ` Robert Dewar 1 sibling, 1 reply; 62+ messages in thread From: Ed Falis @ 1999-10-18 0:00 UTC (permalink / raw) On Mon, 18 Oct 1999 01:23:27 GMT, Robert Dewar <robert_dewar@my-deja.com> wrote: > In article <38077EB3.E6911567@mitre.org>, > "Robert I. Eachus" <eachus@mitre.org> wrote: > > Brian Rogoff wrote: > > > > AFIAK, it is almost always poor engineering to declare > procedures > > within other procedures in Ada. The chief exception is > recursive descent > > parsers. > > What an *amazing* statement. I am completely flabbergasted! Just so it's clear (which it's not from the quoting above), I'm pretty sure it was Eachus, not Rogoff, who made the comment this starts with. - Ed ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-18 0:00 ` Ed Falis @ 1999-10-19 0:00 ` Robert Dewar 0 siblings, 0 replies; 62+ messages in thread From: Robert Dewar @ 1999-10-19 0:00 UTC (permalink / raw) In article <1103_940211488@DZOG-CHEN>, falis@ma.aonix.com (Ed Falis) wrote: > On Mon, 18 Oct 1999 01:23:27 GMT, Robert Dewar <robert_dewar@my-deja.com> wrote: > > In article <38077EB3.E6911567@mitre.org>, > > "Robert I. Eachus" <eachus@mitre.org> wrote: > > > Brian Rogoff wrote: > > > > > > AFIAK, it is almost always poor engineering to declare > > procedures > > > within other procedures in Ada. The chief exception is > > recursive descent > > > parsers. > > > > What an *amazing* statement. I am completely flabbergasted! > > Just so it's clear (which it's not from the quoting above), I'm pretty > sure it was Eachus, not Rogoff, who made the comment this > starts with. > > - Ed > Yes, I understood it to be a comment from Eachus, and that's why I was flabbergasted :-) If it had been from some one else, I would not have been so suprised :-) :-) Sorry for unclear quoting Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
[parent not found: <7u86su$o5v$1@nntp8.atl.mindspring.net>]
* Re: Self-referential types [not found] ` <7u86su$o5v$1@nntp8.atl.mindspring.net> @ 1999-10-18 0:00 ` Robert I. Eachus 1999-10-22 0:00 ` Richard D Riehle 0 siblings, 1 reply; 62+ messages in thread From: Robert I. Eachus @ 1999-10-18 0:00 UTC (permalink / raw) It is nice to be so respectfully disagreed with by so many people, and so quickly too. ;-) However, I don't think they are really disagreeing with my point, just with the words I used to say it. Let's say you have an otherwise large subprogram, with a lot of complexity and a lot of hidden scope variables and data, you have two choices of how to implement it: You can create a procedure or function with a lot of other nested subprograms, or You can create a package with the shared state in the body, and the previous complex procedure as a public interface to that package. In Ada you should almost always (there are those words again) choose the later. The exceptions tend to be those cases where the enclosing subprogram has lots of record or array parameters. But that is normaly bad programming practice. To specifically address Richard Riehle's comments, I tend to do the same thing as he does with case statements, but I unnest the case alternatives and put them in a package. If there is local state needed from the enclosing procedure, I make it a generic package and instantiate it locally to pass the parameters of the enclosing procedure. Doing all this takes effort. You have to think about what state is getting passed where. (Unless, of course, you did all that right during detailed design. ;-) I refuse to see that as anything other than a benefit. I can't begin to count the number of times I have caught subtle programming or design bugs this way, and of course the maintenance programmer will love you for it. Well, maybe that is a bit strong. Certainly he or she won't detest you, and may even say hello in the hallway or the cafeteria. Of course, if you get stuck with the maintenance job, you will find yourself saying, "Gee, I'm glad I did this right," rather than "What the hell was I thinking when I wrote this." I could give examples, but why bother. Everyone reading this must have had the experience of a subtle bug caused by undocumented (and usually unintended) coupling between otherwise unrelated units. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-18 0:00 ` Robert I. Eachus @ 1999-10-22 0:00 ` Richard D Riehle 1999-10-22 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 62+ messages in thread From: Richard D Riehle @ 1999-10-22 0:00 UTC (permalink / raw) In article <380BA036.E9F51F22@mitre.org>, "Robert I. Eachus" <eachus@mitre.org> wrote: > To specifically address Richard Riehle's comments, I tend to do the >same thing as he does with case statements, but I unnest the case >alternatives and put them in a package. If there is local state needed >from the enclosing procedure, I make it a generic package and >instantiate it locally to pass the parameters of the enclosing >procedure. I agree with this principal. In fact, with the advent of private child packages, one can promote these little procedures to a next level above the procedure in which they would have been nested and leverage their visibility through private package specifications within the same parent-child hierarchy. As you so carefully note in your message, this does require some planning. In a large-scale development effort, planning at this level of detail is often absent from the process. Richard Riehle http://www.adaworks.com ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-22 0:00 ` Richard D Riehle @ 1999-10-22 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 62+ messages in thread From: Robert I. Eachus @ 1999-10-22 0:00 UTC (permalink / raw) Richard D Riehle wrote: > As you so carefully note in your > message, this does require some planning. In a large-scale development > effort, planning at this level of detail is often absent from the > process. I think that this really sums it all up. Fortunately less often recently, I get put on "Red Teams" to decide if some project can be saved, and if so how. (And for how much, or whether it is better to cancel it anyway.) So from my experience, too many nested procedures is an indication of (very) bad design. As I also said, nested functions, usually small, don't seem to imply bad design, but nested procedures do. If I were to make this a serious metric by itself, I would use something like, for each procedure start with zero. Climb to the root, and for each nesting, if inside another subprogram or task entry add one. Sum over all procedures and divide by the number of procedures to normalize. I could then set up a scale: 0.1 or less very good,...0.5 acceptable, >1.5 reject. I don't for two reasons. First I have some coupling measures which do a better job, and second, you don't need a scale. Most code is either near zero, around one, or over three... In fact, MITRE did do a lot of work on coupling and cohesion measures using DIANA a few years ago--I would lie to update the tools to use ASIS. But in reality, these tools were of no use at all. The results were either, "Gee, this is just short of perfection, can you do anything about package XXX?" or "This code sucks, but you knew that just from the effort to get it processed by the front-end of the tool. There is no reason to tell you where it sucks or how to fix it. But if you care the answers are 'everywhere' and 'don't'." Incidently, I took a look at some of the GNAT library packages. For almost all of them, the count as expressed above would be zero. The exceptions? Explicit finite state such as in GNAT.Regexp, where such structure is completely justified. But while Robert Dewar and I may write such code, most programmers never do. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 62+ messages in thread
[parent not found: <slrn80fl9f.68j.aidan@skinner.demon.co.uk>]
* Re: Self-referential types [not found] ` <slrn80fl9f.68j.aidan@skinner.demon.co.uk> @ 1999-10-19 0:00 ` Wes Groleau 1999-10-21 0:00 ` Robert Dewar 0 siblings, 1 reply; 62+ messages in thread From: Wes Groleau @ 1999-10-19 0:00 UTC (permalink / raw) > Personally I use (at least I try too, I don't always succeed) nested > procedures to increase code clarity. It generally has that effect for me. > This reduces the overall clutter in a unit, and I find it a lot easier > to check my overall logic if I do this, it doesn't eliminate the need > for comments (or indeed, proper written documentation), but it does > make the program easier to understand. YMMV. If good naming conventions are used, it can _greatly_ reduce the need for comments. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-19 0:00 ` Wes Groleau @ 1999-10-21 0:00 ` Robert Dewar 1999-10-21 0:00 ` Jean-Pierre Rosen ` (3 more replies) 0 siblings, 4 replies; 62+ messages in thread From: Robert Dewar @ 1999-10-21 0:00 UTC (permalink / raw) In article <380CA5AC.82499FE2@ftw.rsc.raytheon.com>, Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote: > If good naming conventions are used, it can _greatly_ reduce > the need for comments. My own view is that good names are an *adjunct* to good comments, not a substitute for them. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-21 0:00 ` Robert Dewar @ 1999-10-21 0:00 ` Jean-Pierre Rosen 1999-10-21 0:00 ` Robert Dewar 1999-10-21 0:00 ` Comments (was: Self-referential types) Wes Groleau ` (2 subsequent siblings) 3 siblings, 1 reply; 62+ messages in thread From: Jean-Pierre Rosen @ 1999-10-21 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 949 bytes --] Robert Dewar <robert_dewar@my-deja.com> a �crit dans le message : 7um9ji$dor$1@nnrp1.deja.com... > In article <380CA5AC.82499FE2@ftw.rsc.raytheon.com>, > Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote: > > If good naming conventions are used, it can _greatly_ reduce > > the need for comments. > > My own view is that good names are an *adjunct* to good > comments, not a substitute for them. > I would say it the other way round: Not everything can be put in good names, therefore comments are necessary to express what cannot be put in the name. But if the info is in the name, then it is repeated each time it is used; therefore, I would discourage something like this: LL : Natural ; -- this is the line length in favour of the (comment-less): Line_Length : Natural; -- --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://pro.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-21 0:00 ` Jean-Pierre Rosen @ 1999-10-21 0:00 ` Robert Dewar 0 siblings, 0 replies; 62+ messages in thread From: Robert Dewar @ 1999-10-21 0:00 UTC (permalink / raw) In article <7un1me$6jm$1@wanadoo.fr>, "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote: > LL : Natural ; -- this is the line length > > in favour of the (comment-less): > Line_Length : Natural; Yes, but I am guessing that in context I would not like EITHER of these alternatives, instead probably what is needed is something like: Line_Length : Natural; -- This is the length of the current line, not including the -- terminating control characters. It is set each time a new -- command is processed, and reflects the length of the command -- after stripping trailing spaces. Well the details will vary, but you get the idea, comments very often need to express far more detail than can be contained in a reasonable length name. If anything, the name Line_Length is more dangerous than LL in this regard, since it can seduce the programmer into thinking that documentation is not required. I actually prefer a rule that says that comments should be independent of names. Yes, that might lead to overcommenting in some rare instances, but that's a disease that I can put up with much better than the serious epidemic of under commenting :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Comments (was: Self-referential types) 1999-10-21 0:00 ` Robert Dewar 1999-10-21 0:00 ` Jean-Pierre Rosen @ 1999-10-21 0:00 ` Wes Groleau 1999-10-21 0:00 ` Ehud Lamm ` (2 more replies) 1999-10-21 0:00 ` Self-referential types Larry Kilgallen 1999-10-22 0:00 ` Richard D Riehle 3 siblings, 3 replies; 62+ messages in thread From: Wes Groleau @ 1999-10-21 0:00 UTC (permalink / raw) > > If good naming conventions are used, [nested procedures] > > CAN greatly reduce the need for comments. > > My own view is that good names are an *adjunct* to good > comments, not a substitute for them. My own view is comments like the following are worse than unnecessary, they are pure clutter: -- check whether the current transaction is completed if Is_Completed (Current_Transaction) then -- if so, close the source and destination DB files DB_IO.Close (Source); DB_IO.Close (Destination); I can't count the number of times I have seen code (in many languages) with many useless comments like the above, but with NONE of the comments it really needed. I suspect "my own view" and "your own view" are the same, but we're applying them to different things. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Comments (was: Self-referential types) 1999-10-21 0:00 ` Comments (was: Self-referential types) Wes Groleau @ 1999-10-21 0:00 ` Ehud Lamm 1999-10-22 0:00 ` Ted Dennison 1999-10-23 0:00 ` Robert Dewar 1999-10-23 0:00 ` M. [not found] ` <Pine.A41.3.96-heb-2.07.991021191504.30582K-100000@pluto.mscc.huji. <381477c9.e1388ff3@ftw.rsc.raytheon.com> 2 siblings, 2 replies; 62+ messages in thread From: Ehud Lamm @ 1999-10-21 0:00 UTC (permalink / raw) On Thu, 21 Oct 1999, Wes Groleau wrote: |My own view is comments like the following are worse than |unnecessary, they are pure clutter: | |-- check whether the current transaction is completed |if Is_Completed (Current_Transaction) then | See my "Guidelines for checking exerices" on my Ada page, section 4. It is stated rather extermely, so don't jump on me... Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== My home on the web Check it out and subscribe to the E-List- for interesting essays and more! ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Comments (was: Self-referential types) 1999-10-21 0:00 ` Ehud Lamm @ 1999-10-22 0:00 ` Ted Dennison 1999-10-23 0:00 ` Ehud Lamm 1999-10-23 0:00 ` Robert Dewar 1 sibling, 1 reply; 62+ messages in thread From: Ted Dennison @ 1999-10-22 0:00 UTC (permalink / raw) In article <Pine.A41.3.96-heb-2.07.991021191504.30582K-100000@pluto.mscc.huji.ac.il >, Ehud Lamm <mslamm@mscc.huji.ac.il> wrote: > On Thu, 21 Oct 1999, Wes Groleau wrote: > > |My own view is comments like the following are worse than > |unnecessary, they are pure clutter: > | > |-- check whether the current transaction is completed > |if Is_Completed (Current_Transaction) then > | > > See my "Guidelines for checking exerices" on my Ada page, section 4. > It is stated rather extermely, so don't jump on me... I generally disagree with #5 (using some brainless "naming convention" to distinguish types/variables/constants rather than simply naming them appropriately for the job they do). But, as has been shown here numerous times in the past, its a quite debatable point. However, it might be a good idea to point out the more contraversial points of your standard to your students, so that they are exposed to the pro and con viewpoints. They still have to follow *your* standard in class, of course. :-) -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Comments (was: Self-referential types) 1999-10-22 0:00 ` Ted Dennison @ 1999-10-23 0:00 ` Ehud Lamm 0 siblings, 0 replies; 62+ messages in thread From: Ehud Lamm @ 1999-10-23 0:00 UTC (permalink / raw) In article <7uponp$s4h$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > In article > > I generally disagree with #5 (using some brainless "naming convention" > to distinguish types/variables/constants rather than simply naming them > appropriately for the job they do). But, as has been shown here numerous > times in the past, its a quite debatable point. > > However, it might be a good idea to point out the more contraversial > points of your standard to your students, so that they are exposed to > the pro and con viewpoints. They still have to follow *your* standard in > class, of course. :-) > > -- > T.E.D. I already posted a reply, but since it seems that it got lost somewhere inside deja, I'll give the gist of it again. My students and I debate most of these issues, anyway. My 'philosophy' is best captured by guidline #9: explanations and reasoning are much more important than any God-like rule. I much prefer understanding to following orders... P.S If someone did see my previous reply, let me know. It is really intriguing to know where it ended up... :-) -- Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm Check it out and subscribe to the E-List Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Comments (was: Self-referential types) 1999-10-21 0:00 ` Ehud Lamm 1999-10-22 0:00 ` Ted Dennison @ 1999-10-23 0:00 ` Robert Dewar 1999-10-23 0:00 ` Ehud Lamm 1 sibling, 1 reply; 62+ messages in thread From: Robert Dewar @ 1999-10-23 0:00 UTC (permalink / raw) In article <Pine.A41.3.96-heb-2.07.991021191504.30582K-100000@pluto.mscc.hu ji.ac.il>, Ehud Lamm <mslamm@mscc.huji.ac.il> wrote: >4. Don't put in too many comments in the code. I want tov be able to see >the code itself. Do not have comments like "loop from 1 to 10" - I can >read the code. Comments SHOULD appear at the start of logical sections >(those that have a specific functionality). I think this is dangerous advice to students, since they hate commenting, and a suggestion that puts the don't in front of the "do" here is upside down. Over-commenting is easily correctable, a life long aversion to writing any comments, which seems to aflict many programmers, is hard or impossible to cure. At first students will tend to over comment a bit, because they don't understand the code as well as you do, but I think it is a tactical mistake to step on that tendency to early on. >5. Use a coding convention that distinguishes types/variables and >constants. I suggest name like "Student_Record" for variables (first >letter capitalized), names like MAXSTUDENT fro constants, and names like >student_record_type for types. But you may choose you own. After you >choose, stick to one standard. I do not consider this helpful at all, and I particularly dislike the C-style all caps for constants. So I agree with Ted here. I don't think that arbitrary rules like this are the least bit helpful X : Universal_Integer_Type; is ugly, when obviously the name Universal_Integer is a noun that is just right for use as a type name. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Comments (was: Self-referential types) 1999-10-23 0:00 ` Robert Dewar @ 1999-10-23 0:00 ` Ehud Lamm 1999-10-23 0:00 ` Comments Georg Bauhaus 1999-10-25 0:00 ` Comments (was: Self-referential types) Wes Groleau 0 siblings, 2 replies; 62+ messages in thread From: Ehud Lamm @ 1999-10-23 0:00 UTC (permalink / raw) In article <7ur1gn$q5h$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > In article > <Pine.A41.3.96-heb-2.07.991021191504.30582K-100000@pluto.mscc.hu > ji.ac.il>, > Ehud Lamm <mslamm@mscc.huji.ac.il> wrote: > >4. Don't put in too many comments in the code. I want tov be > able to see > >the code itself. > > I think this is dangerous advice to students, since they hate > commenting, > and a suggestion that puts the don't in front of the "do" here > is upside > down. Over-commenting is easily correctable, a life long > aversion to > writing any comments, which seems to aflict many programmers, is > hard > or impossible to cure. At first students will tend to over > comment a bit, > because they don't understand the code as well as you do, but I > think it is > a tactical mistake to step on that tendency to early on. > I make my student comment like crazy. This just points out that really useless comments are not what I am looking for. I, like you, am very much in favour of thourgh commenting - and no studunet of mine can fail to notice that after seeing the remarks on his first exercise... > But you may choose you own. > After you > >choose, stick to one standard. This is the major part of the guideline, which both you and Ted didn't appreciate. >I particularly dislike the > C-style all caps for constants. So I agree with Ted here. I > don't > think that arbitrary rules like this are the least bit helpful > > X : Universal_Integer_Type; > > is ugly, when obviously the name Universal_Integer is a noun > that is just > right for use as a type name. > Most of the time, esp. in Ada I agree that name like Index_Type and Number_type are not verey elegant. I prefer giving good names (for example following the noun/adjective distinction etc.) - and this is why (among other reasons) I am willing to accept almost any half decent standard -as long as the programmer is consistent. don't call one variable AVARIABLE and the next on iVAR (following Hungarian). Decide what you prefer. We can argue about your choice, but at this is a legitimate argument - in most cases. So why did I give the advice I gave, which both you and Ted don't li,e, and which I myself am not willing to defend "to the death?" Well, you have to remember that for most of my students English is a foreign language. So they tend to use bad names - for lack of vocab or language skills. They tend to miss the noun/verb distinction when naming functions and procedures etc. So instead of saying "choose good names," which may leave them in the dark I give one solution - even if it is not great. They are free to choose their own naming scheme. Usually I don't really mind - so long as the code is readable. One more reason for the guideline is that I want the guidlines to provide information, that may otherwise be lacking. So I prefer giving an exmaple of a standard - even if it is not desribed completly, just so that the students will have a better grasp of what I am talking about. Consider waht I require from comments. I say 'name, student number, question number, and general description of routine." Of course for a hefty package this is barely enough. I know that, and so do they. This is just a beginning. When I teach about packages, ADTs, ADOs - I take time to discuss what seems reasonable to include in the comments accompanying such modules. Thanks for your comments. Maybe some student will see them, and we will have a discussion about it.... -- Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm Check it out and subscribe to the E-List Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Comments 1999-10-23 0:00 ` Ehud Lamm @ 1999-10-23 0:00 ` Georg Bauhaus 1999-10-24 0:00 ` Comments Ehud Lamm 1999-10-25 0:00 ` Comments (was: Self-referential types) Wes Groleau 1 sibling, 1 reply; 62+ messages in thread From: Georg Bauhaus @ 1999-10-23 0:00 UTC (permalink / raw) Ehud Lamm <mslamm@mscc.huji.ac.il> wrote: : Well, you have to remember that for most of my students : English is a foreign language. So they tend to use bad : names - for lack of vocab or language skills. They tend to : miss the noun/verb distinction when naming functions and : procedures etc. So, wouldn't it seem advisable to have "Natural Language Skills" in the curriculum? At least for non-english speakers (like me :-|)? While there is ongoing talk about The Globalisation (again), I can see that students are advised to learn a foreign language, but are otherwise left alone - the plans for their time at universities do not, in general, explicitely include slots for other skill that are nevertheless considered essential. As an aside, knowing how to use a typewriter seems also to be helpful, yet this isn't taught, is it? :-) -# Georg Bauhaus ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Comments 1999-10-23 0:00 ` Comments Georg Bauhaus @ 1999-10-24 0:00 ` Ehud Lamm 1999-10-26 0:00 ` Comments Robert I. Eachus 0 siblings, 1 reply; 62+ messages in thread From: Ehud Lamm @ 1999-10-24 0:00 UTC (permalink / raw) In article <7usvo6$9kq$1@news-hrz.uni-duisburg.de>, Georg Bauhaus <georg@zorro.uni-duisburg.de> wrote: > > So, wouldn't it seem advisable to have "Natural Language > Skills" in the curriculum? At least for non-english speakers > (like me :-|)? While there is ongoing talk about The > Globalisation (again), I can see that students are advised > to learn a foreign language, but are otherwise left alone - > the plans for their time at universities do not, in general, > explicitely include slots for other skill that are nevertheless > considered essential. > The students must pass an exam on English as a second language, or pass an English course. But this just isn't enough. I am all for language skills. Alas most people lack them - even in their native tongues. Most people fial in phrasing questions, so it is natural that student fail in phrasing answers - even when they know them! (By the way: i started a thread on this in several groups, under the title "formulating good questions"). This is whole subject is off topic here. But as often mentioned in other groups Dijkstra suposedly said that you can tell if someone is a good programmer by judging their native language skills. -- Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm Check it out and subscribe to the E-List Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Comments 1999-10-24 0:00 ` Comments Ehud Lamm @ 1999-10-26 0:00 ` Robert I. Eachus 1999-10-28 0:00 ` Comments Jerry van Dijk 0 siblings, 1 reply; 62+ messages in thread From: Robert I. Eachus @ 1999-10-26 0:00 UTC (permalink / raw) Ehud Lamm wrote: > This is whole subject is off topic here. But as often mentioned in other > groups Dijkstra suposedly said that you can tell if someone is a good > programmer by judging their native language skills. Let's not try to make this an urban legend. He said exactly that. Well, I think his exact words were: "The best predictor of a student's success as a software engineer is his skill in using his native native language." In any case, he said it at a software engineering conference in early June 1979--over twenty years ago, ouch! He also said that if he was running a school to teach programming, he would tie the student's hands behind their backs for the first year. In the discussion following, Dijkstra pointed out that to be a compiler developer, you had to speak English, Dutch, German, or Russian as a young child, even if it was not your "milk tongue." -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Comments 1999-10-26 0:00 ` Comments Robert I. Eachus @ 1999-10-28 0:00 ` Jerry van Dijk 1999-10-28 0:00 ` Comments Ted Dennison 0 siblings, 1 reply; 62+ messages in thread From: Jerry van Dijk @ 1999-10-28 0:00 UTC (permalink / raw) In article <38162C84.A762A730@mitre.org> eachus@mitre.org writes: > In the discussion following, Dijkstra pointed out that to be a >compiler developer, you had to speak English, Dutch, German, or Russian >as a young child, even if it was not your "milk tongue." Wow, with three out of four I qualify... :-) :-) -- -- Jerry van Dijk | email: jdijk@acm.org -- Team-Ada | www: stad.dsl.nl/~jvandyk -- Paris, France | Leiden, Holland ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Comments 1999-10-28 0:00 ` Comments Jerry van Dijk @ 1999-10-28 0:00 ` Ted Dennison 0 siblings, 0 replies; 62+ messages in thread From: Ted Dennison @ 1999-10-28 0:00 UTC (permalink / raw) In article <941090045.3snx@jvdsys.stuyts.nl>, jerry@jvdsys.stuyts.nl wrote: > In article <38162C84.A762A730@mitre.org> eachus@mitre.org writes: > > > In the discussion following, Dijkstra pointed out that to be a > >compiler developer, you had to speak English, Dutch, German, or Russian > >as a young child, even if it was not your "milk tongue." > > Wow, with three out of four I qualify... > > :-) :-) > > -- > -- Jerry van Dijk | email: jdijk@acm.org Well, we shouldn't be horribly shocked that he'd make statements calculated to raise our estimation of developers whose last names start with "Dijk". :-) -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Comments (was: Self-referential types) 1999-10-23 0:00 ` Ehud Lamm 1999-10-23 0:00 ` Comments Georg Bauhaus @ 1999-10-25 0:00 ` Wes Groleau 1 sibling, 0 replies; 62+ messages in thread From: Wes Groleau @ 1999-10-25 0:00 UTC (permalink / raw) > One more reason for the guideline is that I want the guidlines to provide > information, that may otherwise be lacking. So I prefer giving an exmaple of > a standard - even if it is not desribed completly, just so that the students > will have a better grasp of what I am talking about. Just make sure it's a GOOD example. Principle of technical writing: When given text which tells what to do, accompanied by an example, many people will follow the example even if it is the opposite of the text. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Comments (was: Self-referential types) 1999-10-21 0:00 ` Comments (was: Self-referential types) Wes Groleau 1999-10-21 0:00 ` Ehud Lamm @ 1999-10-23 0:00 ` M. [not found] ` <Pine.A41.3.96-heb-2.07.991021191504.30582K-100000@pluto.mscc.huji. <381477c9.e1388ff3@ftw.rsc.raytheon.com> 2 siblings, 0 replies; 62+ messages in thread From: M. @ 1999-10-23 0:00 UTC (permalink / raw) Wes Groleau wrote in message <380F2BA5.1EEE15F1@ftw.rsc.raytheon.com>... >My own view is comments like the following are worse than >unnecessary, they are pure clutter: > > -- check whether the current transaction is completed > if Is_Completed (Current_Transaction) then > > -- if so, close the source and destination DB files > DB_IO.Close (Source); > DB_IO.Close (Destination); These are rather benign examples of what I call "duh" comments. In other cases, the names are not so descriptive, and the comments refer to these names, making them especially useless. e.g.: -- Add 2 to st st := st + 2; -- Flibber the Gibbet Flibber(Gibbet); Such comments can arise when the programmer writes the comments first, then the code. This is a good practice IF the programmer uses it to establish the semantic requirements of the code, so that it will be easier to write (and maintain) code that implements them. "Duh" comments defeat this purpose by blurring the distinction between semantic requirements and implementation. M. ^ permalink raw reply [flat|nested] 62+ messages in thread
[parent not found: <Pine.A41.3.96-heb-2.07.991021191504.30582K-100000@pluto.mscc.huji. <381477c9.e1388ff3@ftw.rsc.raytheon.com>]
* Re: Comments (was: Self-referential types) [not found] ` <Pine.A41.3.96-heb-2.07.991021191504.30582K-100000@pluto.mscc.huji. <381477c9.e1388ff3@ftw.rsc.raytheon.com> @ 1999-10-25 0:00 ` Larry Kilgallen 0 siblings, 0 replies; 62+ messages in thread From: Larry Kilgallen @ 1999-10-25 0:00 UTC (permalink / raw) Reply-To: Kilgallen@eisner.decus.org.nospam Organization: LJK Software Lines: 10 In article <381477C9.E1388FF3@ftw.rsc.raytheon.com>, Wes Groleau <wwgrol@ftw.rsc.raytheon.com> writes: > Just make sure it's a GOOD example. Principle of technical writing: > When given text which tells what to do, accompanied by an example, many > people will follow the example even if it is the opposite of the text. And that is the wisest course if the set of people who miss the normative text includes the proofreaders :-). Larry Kilgallen ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-21 0:00 ` Robert Dewar 1999-10-21 0:00 ` Jean-Pierre Rosen 1999-10-21 0:00 ` Comments (was: Self-referential types) Wes Groleau @ 1999-10-21 0:00 ` Larry Kilgallen 1999-10-22 0:00 ` Richard D Riehle 3 siblings, 0 replies; 62+ messages in thread From: Larry Kilgallen @ 1999-10-21 0:00 UTC (permalink / raw) In article <7um9ji$dor$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: > In article <380CA5AC.82499FE2@ftw.rsc.raytheon.com>, > Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote: >> If good naming conventions are used, it can _greatly_ reduce >> the need for comments. > > My own view is that good names are an *adjunct* to good > comments, not a substitute for them. Well try this wording: If bad naming conventions are used, it can _greatly_ increase the need for comments. Example: declare -- -- Despite what you might infer from our efforts -- to cloak the symbol table, the following -- contains the number of miles to the next city. -- Weight_In_Kilograms : NATURAL := 0; :-) Larry Kilgallen ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-21 0:00 ` Robert Dewar ` (2 preceding siblings ...) 1999-10-21 0:00 ` Self-referential types Larry Kilgallen @ 1999-10-22 0:00 ` Richard D Riehle 1999-10-23 0:00 ` Robert A Duff 1999-10-24 0:00 ` Michel DELARCHE 3 siblings, 2 replies; 62+ messages in thread From: Richard D Riehle @ 1999-10-22 0:00 UTC (permalink / raw) In article <7um9ji$dor$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: >My own view is that good names are an *adjunct* to good >comments, not a substitute for them. Many software products developed in Ada are based on some larger systems engineering specification. The software must reflect the constraints of that specification. For example, in one communications satellite software effort, it was common to see comments that referred back to a paragraph of the engineering specification. It would have been quite foolhardy to rely only on the names of the entities. Many of these names described some complicated calculation that could only be understood by looking at the underlying mathematics in the engineering specification. For trivial programs in which one is simply getting and putting data to and from files, meaningful names might be enough. For serious engineering applications, we need comments that correspond to the original specification. As usual, we use the kind of tools appropriate for the problem space and solution space. I am beginning to think that people who make up hard and fast rules for computer programming are people who no longer actually write programs. Perhaps they never did. Richard Riehle http://www.adaworks.com ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-22 0:00 ` Richard D Riehle @ 1999-10-23 0:00 ` Robert A Duff 1999-10-23 0:00 ` Richard D Riehle 1999-10-24 0:00 ` Michel DELARCHE 1 sibling, 1 reply; 62+ messages in thread From: Robert A Duff @ 1999-10-23 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > As usual, we use the kind of tools appropriate for the problem > space and solution space. I am beginning to think that people who > make up hard and fast rules for computer programming are people who > no longer actually write programs. Perhaps they never did. Hmm. I had a hand in writing a book that's got thousands of absolutely hard and fast rules for programming. It's the Ada 95 Reference Manual. And I still actually write programs. ;-) ;-) - Bob ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-23 0:00 ` Robert A Duff @ 1999-10-23 0:00 ` Richard D Riehle 0 siblings, 0 replies; 62+ messages in thread From: Richard D Riehle @ 1999-10-23 0:00 UTC (permalink / raw) In article <wccu2ni3weo.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: in response to the following outrageous hyperbole, >Richard D Riehle <laoXhai@ix.netcom.com> writes: > >> As usual, we use the kind of tools appropriate for the problem >> space and solution space. I am beginning to think that people who >> make up hard and fast rules for computer programming are people who >> no longer actually write programs. Perhaps they never did. > >Hmm. I had a hand in writing a book that's got thousands of absolutely >hard and fast rules for programming. It's the Ada 95 Reference Manual. >And I still actually write programs. ;-) ;-) Robert, This is not at all the same thing. The formulation of a syntax and semantics for a programming language is not, in my mind, the equivalent of telling a programmer which of those language features to use or not use. I realize that many programmers resent Ada because they feel it does impose too many rules. I would not want to return to Assembler, even though there are fewer language rules. Even so, I still encounter those elitists who would rather program in Assembler because high-order languages are too restrictive. To them, those of us _sissies_ who no longer program in Assembler are not really programmers. The kind of people mentioned in my post are those who thumb through your program and criticize you for having an exit statement in a loop, a use or use type clause in a perfectly safe place, a goto when it is absolutely necessary, or some other construct they read about somewhere in some magazine. For example, when Dijkstra published his famous CACM letter, "Go To Considered Harmful," thousands of programming managers who did not read the article adopted the title as a standard, thereby screwing up millions of lines of COBOL code. COBOL, at that time, was completely inappropriate for structured methods, and attempts to produce structured code resulted in some of the most obfuscated constructs one could imagine. Taking the Ada example. The rules of Ada are certainly strict. That is not a bad thing. It would have been a bad thing if there were no mechanisms for relaxing those strict rules when it was appropriate. One reason Ada is better than Java for lots of things is the ability to relax the rules. So, Robert, even though you were involved in writing a language that has lots of rules, you and others engaged in this effort had the good sense to include capabilities for suspending those rules when the correct solution called for it. Consequently, I would not include you and the other designers of Ada in my outrageous hyperbole. You wrote a language reference manual that said, "These are the default rules. Use them and be safe." Then you added, "These are the workarounds when you need them." Richard Riehle http://www.adaworks.com ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-22 0:00 ` Richard D Riehle 1999-10-23 0:00 ` Robert A Duff @ 1999-10-24 0:00 ` Michel DELARCHE 1 sibling, 0 replies; 62+ messages in thread From: Michel DELARCHE @ 1999-10-24 0:00 UTC (permalink / raw) To: Richard D Riehle A telling anecdote about name-based vs. comment-based "clarity": in one of my previous lives I was part of a team developing Fortran software with the 8-character limitations in names etc. ; one variable that would read CAPENDEG (an easily understandable French abbreviation for "Heading-in-degrees") would not need any additional comment, either on a stand-alone basis or by means of reference to previous specification documents. The nag is that neither the military airmen writing the high level specifications with the "obvious" assumption that they were talking about magnetic headings nor the software engineers who were developing the software with the (not less "obvious") assumption that they were dealing with geographic headings, realised the misunderstanding until the first mapped trajectories came out of the system, looking slightly tilted to the trained eyes of the aviators. Both groups realised then that both the initial specifications and the subsequent software implementation had missed something. More expressive languages like Ada might have defined a more strict (sub)type and even a unit system (cf. the recent thread on the Mars Orbiter crash), but I'm still not sure that the "obvious" distinction between magnetic and geographic heading would have popped up earlier that it did. Based on my (past) experience of software development for a variety of application fields, I think that the main problem with software documentation integrity and maintainability is precisely that kind of diverging implicit assumptions made by dedicated yet necessarily rather narrowly trained professionals that fail to realise that what is "obvious" to them may not be so "obvious" to someone else. Richard D Riehle a �crit : > In article <7um9ji$dor$1@nnrp1.deja.com>, > Robert Dewar <robert_dewar@my-deja.com> wrote: > > >My own view is that good names are an *adjunct* to good > >comments, not a substitute for them. > > Many software products developed in Ada are based on some > larger systems engineering specification. The software must > reflect the constraints of that specification. For example, > in one communications satellite software effort, it was common > to see comments that referred back to a paragraph of the > engineering specification. > > It would have been quite foolhardy to rely only on the names of > the entities. Many of these names described some complicated > calculation that could only be understood by looking at the > underlying mathematics in the engineering specification. For > trivial programs in which one is simply getting and putting > data to and from files, meaningful names might be enough. For > serious engineering applications, we need comments that correspond > to the original specification. > > As usual, we use the kind of tools appropriate for the problem > space and solution space. I am beginning to think that people who > make up hard and fast rules for computer programming are people who > no longer actually write programs. Perhaps they never did. > > Richard Riehle > http://www.adaworks.com > ^ permalink raw reply [flat|nested] 62+ messages in thread
[parent not found: <3802597B.9205AEE8@averstar.com>]
* Re: Self-referential types [not found] ` <3802597B.9205AEE8@averstar.com> @ 1999-10-12 0:00 ` Ted Dennison 1999-10-12 0:00 ` Matthew Heaney 0 siblings, 1 reply; 62+ messages in thread From: Ted Dennison @ 1999-10-12 0:00 UTC (permalink / raw) In article <3802597B.9205AEE8@averstar.com>, Tucker Taft <stt@averstar.com> wrote: > Ted Dennison wrote: > > > > Below is a code sample that is taken directly from Cohen's AAASL, > > section 11.8.3: > > > > procedure Test is > > > > type Cell_Type; > > > > type List_Type is access all Cell_Type; > > > > type Cell_Type is > > limited record > > Contents_Part : String (1..20); > > Next_Cell_Part : List_Type := Cell_Type'Access; > > Previous_Cell_Part : List_Type := Cell_Type'Access; > > end record; > invokes the various accessibility rules. In particular, when > inside the definition of a type, <type_name>'Access is presumed > to have an accessibility level deeper than that of the enclosing type, > meaning it is also deeper than List_Type. Note that there is > nothing preventing the values of next and previous being copied > into global variables, whereas you might have a local object of type > Cell_Type. OK. After masticating on this parargraph for a while, I think what you are saying is that I theoreticly could do this: Global : List_Type; procedure Local is Cell : Cell_Type; begin Global := Cell.Next_Cell_Part; end Local; ..and then after a call to Local, I now have in Global a pointer into unallocated stack space. I think what was confusing me was that I'm used to thinking about accessability levels in record *objects*, not types. But I can't speak for what was confusing Cohen. :-) > To avoid the use of "'Unchecked_Access" you could simply default > initialize to "null," You could define a separate function to do the ..or use a second null record with an access discriminant, as I have seen done elsewhere. -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Ted Dennison @ 1999-10-12 0:00 ` Matthew Heaney 1999-10-13 0:00 ` Ted Dennison 0 siblings, 1 reply; 62+ messages in thread From: Matthew Heaney @ 1999-10-12 0:00 UTC (permalink / raw) In article <7tvgud$qh7$1@nnrp1.deja.com> , Ted Dennison <dennison@telepath.com> wrote: > I think what was confusing me was that I'm used to thinking about > accessability levels in record *objects*, not types. But it *is* an object. Inside the declaration of a limited type T, the expression T'Access refers to the "current instance" of the type. > But I can't speak for what was confusing Cohen. :-) I don't understand why you have a smiley there. Are you saying there's a mistake in Ada As A 2nd Language? If so, on what page? Perhaps there is just a misunderstanding about what Norm was saying. Matt -- Creationists attempt to draw a line between evolutionary biology and the rest of science by remarking that large-scale evolution cannot be observed. This tactic fails. Large-scale evolution is no more inaccessible to observation than nuclear reactions or the molecular composition of water. Abusing Science: The Case Against Creationism Philip Kitcher ^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: Self-referential types 1999-10-12 0:00 ` Matthew Heaney @ 1999-10-13 0:00 ` Ted Dennison 0 siblings, 0 replies; 62+ messages in thread From: Ted Dennison @ 1999-10-13 0:00 UTC (permalink / raw) In article <3803bd26_4@news1.prserv.net>, "Matthew Heaney" <matthew_heaney@acm.org> wrote: > In article <7tvgud$qh7$1@nnrp1.deja.com> , Ted Dennison > <dennison@telepath.com> wrote: > > > I think what was confusing me was that I'm used to thinking about > > accessability levels in record *objects*, not types. > > But it *is* an object. Inside the declaration of a limited type T, the > expression T'Access refers to the "current instance" of the type. But the accessablity problem exists because it is a *type* declaration, not an object declaration. If we were talking about an object declaration, its lifetime would be the same as that of the access type, and there would be no problem. > > But I can't speak for what was confusing Cohen. :-) > > I don't understand why you have a smiley there. Are you saying > there's a mistake in Ada As A 2nd Language? If so, on what page? > Perhaps there is just a misunderstanding about what Norm was saying. To quote from my original posting: Below is a code sample that is taken directly from Cohen's AAASL, section 11.8.3: I'm looking at a copy of the second edition. Page numbers can vary in different printings. But in my copy this part of 11.8.3 is on page 491. My suspicion is that he got bit by using an early version of Gnat to compile his examples. I have a very foggy memory that accessability checks possibly weren't put into Gnat until late '96 or so (I remember a minor brouhaha resulting from a lot of incorrectly coded Ada95 sources suddenly breaking on Gnat users). His book is copyrighted 1996. -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 62+ messages in thread
end of thread, other threads:[~1999-10-28 0:00 UTC | newest] Thread overview: 62+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <7ttb4a$8mq$1@nnrp1.deja.com> 1999-10-12 0:00 ` Self-referential types Robert A Duff 1999-10-12 0:00 ` Vladimir Olensky 1999-10-12 0:00 ` Matthew Heaney 1999-10-12 0:00 ` Richard D Riehle 1999-10-12 0:00 ` news.oxy.com 1999-10-12 0:00 ` Ted Dennison 1999-10-12 0:00 ` Stanley R. Allen 1999-10-13 0:00 ` Ted Dennison 1999-10-13 0:00 ` Vladimir Olensky 1999-10-14 0:00 ` Multiple Inheritance in Ada 95 [was Re: Self-referential types] Tucker Taft 1999-10-12 0:00 ` Self-referential types Matthew Heaney 1999-10-12 0:00 ` Ted Dennison 1999-10-12 0:00 ` Matthew Heaney 1999-10-12 0:00 ` Robert I. Eachus 1999-10-12 0:00 ` Matthew Heaney 1999-10-13 0:00 ` Ted Dennison 1999-10-13 0:00 ` Matthew Heaney 1999-10-13 0:00 ` Vladimir Olensky 1999-10-13 0:00 ` Vladimir Olensky 1999-10-18 0:00 ` Robert Dewar 1999-10-18 0:00 ` Vladimir Olensky 1999-10-18 0:00 ` Laurent Guerby 1999-10-13 0:00 ` Robert I. Eachus 1999-10-13 0:00 ` Brian Rogoff 1999-10-15 0:00 ` Robert I. Eachus 1999-10-15 0:00 ` Marin David Condic 1999-10-15 0:00 ` Robert I. Eachus 1999-10-18 0:00 ` Robert Dewar 1999-10-19 0:00 ` Robert I. Eachus 1999-10-18 0:00 ` Robert Dewar 1999-10-18 0:00 ` Brian Rogoff 1999-10-18 0:00 ` Ed Falis 1999-10-19 0:00 ` Robert Dewar [not found] ` <7u86su$o5v$1@nntp8.atl.mindspring.net> 1999-10-18 0:00 ` Robert I. Eachus 1999-10-22 0:00 ` Richard D Riehle 1999-10-22 0:00 ` Robert I. Eachus [not found] ` <slrn80fl9f.68j.aidan@skinner.demon.co.uk> 1999-10-19 0:00 ` Wes Groleau 1999-10-21 0:00 ` Robert Dewar 1999-10-21 0:00 ` Jean-Pierre Rosen 1999-10-21 0:00 ` Robert Dewar 1999-10-21 0:00 ` Comments (was: Self-referential types) Wes Groleau 1999-10-21 0:00 ` Ehud Lamm 1999-10-22 0:00 ` Ted Dennison 1999-10-23 0:00 ` Ehud Lamm 1999-10-23 0:00 ` Robert Dewar 1999-10-23 0:00 ` Ehud Lamm 1999-10-23 0:00 ` Comments Georg Bauhaus 1999-10-24 0:00 ` Comments Ehud Lamm 1999-10-26 0:00 ` Comments Robert I. Eachus 1999-10-28 0:00 ` Comments Jerry van Dijk 1999-10-28 0:00 ` Comments Ted Dennison 1999-10-25 0:00 ` Comments (was: Self-referential types) Wes Groleau 1999-10-23 0:00 ` M. [not found] ` <Pine.A41.3.96-heb-2.07.991021191504.30582K-100000@pluto.mscc.huji. <381477c9.e1388ff3@ftw.rsc.raytheon.com> 1999-10-25 0:00 ` Larry Kilgallen 1999-10-21 0:00 ` Self-referential types Larry Kilgallen 1999-10-22 0:00 ` Richard D Riehle 1999-10-23 0:00 ` Robert A Duff 1999-10-23 0:00 ` Richard D Riehle 1999-10-24 0:00 ` Michel DELARCHE [not found] ` <3802597B.9205AEE8@averstar.com> 1999-10-12 0:00 ` Ted Dennison 1999-10-12 0:00 ` Matthew Heaney 1999-10-13 0:00 ` Ted Dennison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox