* Child package: private type and IO @ 1998-02-14 0:00 johnjohn 1998-02-16 0:00 ` Tom Moran 1998-02-17 0:00 ` sparre 0 siblings, 2 replies; 14+ messages in thread From: johnjohn @ 1998-02-14 0:00 UTC (permalink / raw) I'm trying to write two separate packages, one for a private type and constructor, and the other an IO package. House rules. :( The need, obviously, is for the IO package to be able to access the private type internals, a feature which seems to be supported via the child package system. It's unclear to me, however, exactly how a package is declared to be a child of the original. Picking up Skansholm's Ada From the Beginning, usually a pretty good resource, is particularly emptly on package externals (file extensions, for example). Actually, now that I say that, Skansholm does have a reference to naming a child package "PARENT_PKG.CHILD_NAME". However, using this convention gets me the following compilation error on the "with" declaration: file "parent_pkg-child_name.ads" not found Any tips? Any pointers to a better handling of child packages? Thanks. John ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Child package: private type and IO 1998-02-14 0:00 Child package: private type and IO johnjohn @ 1998-02-16 0:00 ` Tom Moran 1998-02-17 0:00 ` sparre 1 sibling, 0 replies; 14+ messages in thread From: Tom Moran @ 1998-02-16 0:00 UTC (permalink / raw) >to naming a child package "PARENT_PKG.CHILD_NAME". But a child needn't 'with' its parent - that, and 'use', are automatic. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Child package: private type and IO 1998-02-14 0:00 Child package: private type and IO johnjohn 1998-02-16 0:00 ` Tom Moran @ 1998-02-17 0:00 ` sparre 1998-02-27 0:00 ` Matthew Heaney 1 sibling, 1 reply; 14+ messages in thread From: sparre @ 1998-02-17 0:00 UTC (permalink / raw) John <johnjohn@triceratops.com> wrote: > I'm trying to write two separate packages, one for a private > type and constructor, and the other an IO package. House > rules. :( Good rules! I would have been nice if you posted more code (and told us that you are using GNAT :-). GNAT has some rather strict rules for the names of source files. If you are in doubt about them, run "gnatchop" on your individual source files, and see how it splits the source up and names the files. A parent-client package example: -- file: parent.ads package Parent is type Object is ...; function Initialise return Object; end Parent; -- file: parent-child.ads with Ada.Text_IO; package Parent.Child is procedure Put (File : in Ada.Text_IO.File_Type; Item : in Object); procedure Get (File : in Ada.Text_IO.File_Type; Item : out Object); end Parent.Child; You will of cause also need implementations (package bodies) for these specifications. Jacob Sparre Andersen -- Have you played with your LEGO today? -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreading ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Child package: private type and IO 1998-02-17 0:00 ` sparre @ 1998-02-27 0:00 ` Matthew Heaney 1998-03-01 0:00 ` type names (was Re: Child package: private type and IO) Ray Blaak 0 siblings, 1 reply; 14+ messages in thread From: Matthew Heaney @ 1998-02-27 0:00 UTC (permalink / raw) In article <6cbuat$cg3$1@nnrp1.dejanews.com>, sparre@cats.nbi.dk wrote: >A parent-client package example: > > -- file: parent.ads > > package Parent is > > type Object is ...; > > function Initialise return Object; > > end Parent; Note that this is NOT the way to organize this package if type Object is tagged. For a tagged type, constructors - defined as functions returning a value of the type - should return the class-wide type, or should be declared in a nested package, ie package P is type T is tagged ...; package Constructors is function New_T return T; end; ... end P; -or- package P is type T is tagged ...; function New_T return T'Class; ... end P; The problem is that very often you use the "transitivity of visibility" technique to get direct visitibility to the type and its operations, with a null extension, ie type NT is new P.T with null record; but if T has primitive operations that are functions returning type T, then type NT "goes abstract," and the poor client has to override them. This is NOT what you want to have happen. By declaring the constructor in a nested package, then the function isn't primitive anymore, and so it is not inherited. Therefore, any derivation doesn't go abstract, because there are not inheritable functions that return the specific type. The same effect may be achieved by making the return type class-wide. Then the function is no longer primitive, and so is not inherited during a derivation. Therefore, the derived type does not go abstract, which is the behavior we want. I'll also make an Ada style point. Please do not name a type "type Object is..." This is VERY confusing, because an object is an object, not a type. Objects are the memory locations that store a value of a type. So when refer to an object's type as "Object," then how do you refer to the object? A type should be named using a noun phrase, such as type Text_File is ...; type Singly_Linked_List is ...; type Storage_Element_Array is array ...; type Ownship_Heading is ...; type Integer is ...; A good guideline is, Be consistant with the style in the reference manual. There are NO types in the RM named "Object," so there should be none in your code either. ^ permalink raw reply [flat|nested] 14+ messages in thread
* type names (was Re: Child package: private type and IO) 1998-02-27 0:00 ` Matthew Heaney @ 1998-03-01 0:00 ` Ray Blaak 1998-03-01 0:00 ` Matthew Heaney 0 siblings, 1 reply; 14+ messages in thread From: Ray Blaak @ 1998-03-01 0:00 UTC (permalink / raw) mheaney@ni.net (Matthew Heaney) writes: >I'll also make an Ada style point. Please do not name a type "type Object >is..." This is VERY confusing, because an object is an object, not a type. I am sure this is a periodic topic that has been rehashed to death, but I can't resist... >Objects are the memory locations that store a value of a type. But you are using the word here as a type! (i.e. the set of things that are memory locations that store values). >So when refer to an object's type as "Object," then how do you refer to the >object? Perhaps as An_Object, or The_List, or The_Set, or even Value. An even better approach is to use names from the domain, like maybe Employees, or Active_Flights, or Current_Account. >A type should be named using a noun phrase, such as >type Singly_Linked_List is ...; I think that style of type names used really depends on if type names are qualified with package names or not. Having: package Linked_List is type Linked_List is ... end Linked_List; results in usage like: Employees : Linked_List.Linked_List; which I personally find irritating. However a package like: package Linked_List is type Object is ... end Linked_List; results in usage like: Employees : Linked_List.Object; which reads better to me. Note this does not imply that all types should be called "Object" either. With this example in particular, it is natural to work with objects and references to objects: type Handle; type Object is record ... Next : Handle; Previous : Handle; end record; type Handle is access Object; then one can say things like: Manager_Subset : Linked_List.Handle; which is really clear (to me, of course :-). If one uses use clauses a lot, then of course more descriptive type names are better: data : Linked_List; >A good guideline is, Be consistant with the style in the reference manual. >There are NO types in the RM named "Object," so there should be none in >your code either. One shouldn't be so afraid to do something different, if one thinks it is an improvement. How else can standards get better? Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: type names (was Re: Child package: private type and IO) 1998-03-01 0:00 ` type names (was Re: Child package: private type and IO) Ray Blaak @ 1998-03-01 0:00 ` Matthew Heaney 1998-03-01 0:00 ` Brian Rogoff 1998-03-04 0:00 ` Fergus Henderson 0 siblings, 2 replies; 14+ messages in thread From: Matthew Heaney @ 1998-03-01 0:00 UTC (permalink / raw) In article <6dcio1$fvo$1@berlin.infomatch.com>, blaak@infomatch.com (Ray Blaak) wrote: >>Objects are the memory locations that store a value of a type. > >But you are using the word here as a type! (i.e. the set of things that are >memory locations that store values). No. You are confused about what a type is. Let's begin by defining what we mean by a type. A type is defined as "A set of values, and a set of operations on those values." For example, I can define a type with the name "Integer" and the set of values ..., -3, -2, -1, 0, 1, 2, 3, ... and the set of operations +: Integer x Integer -> Integer -: Integer x Integer -> Integer *: Integer x Integer -> Integer /: Integer x Integer -> Integer =: Integer x Integer -> Boolean etc A type refers to the set of values, NOT the objects. An object is a memory location inside a computer, that stores a value, a value we interpret as having a certain type. So when we declare an object, O : T; we're allocating a memory cell, and we're interpreting the value of the data in that cell as being of type T. The means the memory cell designated by object O will only contain certain values, and that only certain operations may be applied to the value in that cell. The memory cell designated by object O isn't really interesting. It's the data in that cell that's interesting. And it's the data in the cell that "is of type T," not the object itself. It is completely wrong to name a type "Object." There are 2 reasons: 1) It confuses the difference between a memory cell (which merely stores a value) and the value itself. "Type" refers to a set of values, and to the operations you can perform to manipulate those values. "Type" does NOT refer to the memory cell containing a value. The term we use to refer to a memory cell containing a value is "Object." Yes, it's true we often say "Object O has type T," but we really mean "O is the name of a memory cell containing a value of type T." The name "T" is the name we've bound to the TYPE, not to the object. So "T" is the name by which we refer to a set of values and a set of operations. The name "O" is the name we bind to an OBJECT, not a type; that is, "O" refers to a memory cell. So when you name a type "Object," it's confusing because the term "Object" refers to a memory cell. But a type is NOT a memory call, it's a set of values. 2) It confuses the difference between a module and a type. In Ada, module and type are ORTHOGONAL language features. This really confuses a lot of people, and I have no idea why. The Ada language construct for a module is a package. A package is NOT a type. A package which exports a type declaration merely demarcates the "primitive" operations of a type among all the operations that have the type as a parameter or return value. The Ada language construct for a type comprises 2 parts: a) a type declaration, which binds a name to the type, specifies its class, and specifies the set of values as a range (or implied range). b) subprogram declarations, which take parameters of the type, or return values of the type. Consider this example: package P is type T is range 1 .. 4; procedure Op1 (O : T); function Op2 (F : Float) return T; end P; with P; package Q is procedure Op3 (O : P.T); end Q; Let's analyze this piece by piece. The declaration type T is range 1 .. 4; a) specifies the type class, here Integer b) specifies the set of values (having the Integer class) for the type, here 1, 2, 3, 4 c) binds a name to the type, here "T" d) specifies primitive operations that are "predefined" for this class of type, here +: T x T -> T +: T -> T -: T x T -> T -: T -> T =: T x T -> Boolean etc The operations Op1 and Op2 are also "primitive" operations of the type whose name is T. We say they are "user-defined," in contrast to the "predefined" primitive operations as addition, subtraction, etc. They are primitive because they take a parameter of the type (Op1) and return a value of the type (Op2), and they are declared in the same package (P) as the type declaration. By contrast, the operation Op3 is NOT a "primitive" operation of the type whose name is T. Even though Op3 takes a parameter of type P.T, it is not primitive because it is not declared in the same package as the type declaration. We make the distinction between primitive and non-primitive operations because only the former are "inherited" during a derivation. For example, with P; package R is type NT is new P.T; procedure Op4 (O : NT); end R; The primitive operations of type R.NT are "+", "-", "*", "/", etc, and Op1, Op2, and Op4. Op1 and Op2 (and addition, etc) are inherited from T, and a new primitive operation, Op4, was added too. Note the Op3 is NOT an operation of type NT, because Op3 is not a primitive operation of type T. And by the way, while I'm on the subject, a "class" in other languages as C++, Eiffel, and Java maps to an Ada tagged type. It does NOT map to an Ada package. To convert the C++ declaration class Stack ...; to Ada, you have to do this: package Stacks is type Stack is ...; -- this is the "class Stack" >>So when refer to an object's type as "Object," then how do you refer to the >>object? > >Perhaps as An_Object, or The_List, or The_Set, or even Value. An even better >approach is to use names from the domain, like maybe Employees, or >Active_Flights, or Current_Account. An an even better approach is Account : Bank_Account; File : Text_File; Mode : File_Mode; >>A type should be named using a noun phrase, such as >>type Singly_Linked_List is ...; > >I think that style of type names used really depends on if type names are >qualified with package names or not. Of course, a type name should NOT be qualified by a package name. A type name is a type name, and a package name is a package name. A package name is NOT a type name, and in no way participates in naming a type. A package is a namespace, and serves only to prevent clashes among similarly named types in an otherwise global namespace. A package disambiguates type names, but it is itself not a type name. To use a package as part of the type, as in package P is type Object is ...; ... end P; The_Object : P.Object; so that the "real" type name is "P.Object" only confuses the difference between a module and a type. >Having: > > package Linked_List is > type Linked_List is ... > end Linked_List; > >results in usage like: > > Employees : Linked_List.Linked_List; > >which I personally find irritating. The package is misnamed. A common idiom, and a very OLD idiom in the Ada community, is to use the plural of the type name as the package name, as in generic ... package Stacks type Stack is ...; ...; end Stacks; I'm sorry you find this convention irritating. If so, then you can tell the language designers that they named the packages Ada.Characters Ada.Interrupts Ada.Interrupts.Names Ada.Exceptions Ada.Numerics Ada.Streams Ada.Strings Interfaces Interfaces.C.Pointers Interfaces.C.Strings System.Address_To_Access_Conversions System.Storage_Elements System.Storage_Pools incorrectly, and that the names they chose irritate you. > However a package like: > > package Linked_List is > type Object is ... > end Linked_List; > >results in usage like: > > Employees : Linked_List.Object; > >which reads better to me. It reads better to you because you are confused. You don't understand the difference between a module and a type. >Note this does not imply that all types should be >called "Object" either. With this example in particular, it is natural to work >with objects and references to objects: > > type Handle; > type Object is record > ... > Next : Handle; > Previous : Handle; > end record; > type Handle is access Object; This is another horrible naming convention. The term "handle" loosely refers to a pointer-to-pointer. Handles are used in memory allocation schemes to allow you to relocate chunks of memory to reduce fragmentation (Mac programmers will know what I'm talking about). The Ada idiom for a name of an access type is T_Access, for example type Stack is tagged private; type Stack_Access is access all Stack; type Stack_Class_Access is access all Stack'Class; Do not name an access type Handle, because it is not a handle. Do not name an access type Pointer, because access objects are not pointers. If they were, then Jean Ichbiah would have chosen the keyword "pointer" instead of "access," right? If you don't believe that this is the Ada idiom, then make note of the names of the types Ada.Text_IO.File_Access Ada.Strings.Unbounded.String_Access Ada.Streams.Stream_IO.Stream_Access >then one can say things like: > > Manager_Subset : Linked_List.Handle; > >which is really clear (to me, of course :-). > >If one uses use clauses a lot, then of course more descriptive type names are >better: > > data : Linked_List; Ahh, that's more like it. Here's an example from a library I'm writing: package ACL.Lists is ...; package ACL.Lists.Single is type Single_List is private; ...; end ACL.Lists.Single; package ACL.Lists.Double is type Double_List is private; ... end ACL.Lists.Double; Here's another example you often find in tutorials: package Bank_Accounts is type Bank_Account is abstract tagged limited private; ...; end Bank_Accounts; package Bank_Accounts.Checking is type Checking_Account is new Bank_Account with private; ...; end Bank_Accounts.Checking; package Bank_Accounts.Savings is type Savings_Account is new Bank_Account with private; ... end Bank_Accounts.Savings; >>A good guideline is, Be consistant with the style in the reference manual. >>There are NO types in the RM named "Object," so there should be none in >>your code either. > >One shouldn't be so afraid to do something different, if one thinks it is an >improvement. How else can standards get better? A bunch of guys from all over the planet with PhDs in computer science designed the language, and somehow they didn't come up with your "better idea." Telling, isn't it? If you think it is an improvement, perhaps that is because there is knowledge that you don't have. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: type names (was Re: Child package: private type and IO) 1998-03-01 0:00 ` Matthew Heaney @ 1998-03-01 0:00 ` Brian Rogoff 1998-03-01 0:00 ` Matthew Heaney 1998-03-04 0:00 ` Fergus Henderson 1 sibling, 1 reply; 14+ messages in thread From: Brian Rogoff @ 1998-03-01 0:00 UTC (permalink / raw) On Sun, 1 Mar 1998, Matthew Heaney wrote: > In article <6dcio1$fvo$1@berlin.infomatch.com>, blaak@infomatch.com (Ray > Blaak) wrote: > > >>Objects are the memory locations that store a value of a type. > > > >But you are using the word here as a type! (i.e. the set of things that are > >memory locations that store values). > > No. You are confused about what a type is. > > ... stuff I mostly agree with deleted ... > > In Ada, module and type are ORTHOGONAL language features. This really > confuses a lot of people, and I have no idea why. Many programmers began their OO programming with (early) C++, or Smalltalk, or may have read "Object Oriented Software Construction", and consider the conflation of module and type into class to be fundamental. Perhaps Java programmers and "new C++" programmers will have an easier time of it, but I doubt it. OTOH, in some ways modules can be said to have a "type"; the ML family of languages (of which SML and Objective CAML are instances) have module systems in which modules ("structures" in ML) have "signatures" which are loosely like types, and "functors" which map structures to other structures. Ada now provides some of this via generic formal package parameters and null-bodied generic packages. > Do not name an access type Pointer, because access objects are not > pointers. If they were, then Jean Ichbiah would have chosen the keyword > "pointer" instead of "access," right? Funny, one of the first papers on Ada 9X that I read used "_Ptr" to name access types. I guess you should tell the author that he is confused, even though he was technical director of the design team ;-). > >One shouldn't be so afraid to do something different, if one thinks it is an > >improvement. How else can standards get better? > > A bunch of guys from all over the planet with PhDs in computer science > designed the language, and somehow they didn't come up with your "better > idea." Telling, isn't it? If you think it is an improvement, perhaps that > is because there is knowledge that you don't have. A bunch of guys with PhDs from all over the planet think Ada sucks, some of them are very well respected too. Which PhDs are right? Argument from authority is unhelpful; while I agree (mostly) with every guideline you set forth, and found Ray's naming schemes awful, Ray Blaak is right with his final lines. Try things out if you think you have a better way. -- Brian ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: type names (was Re: Child package: private type and IO) 1998-03-01 0:00 ` Brian Rogoff @ 1998-03-01 0:00 ` Matthew Heaney 1998-03-03 0:00 ` Ray Blaak 0 siblings, 1 reply; 14+ messages in thread From: Matthew Heaney @ 1998-03-01 0:00 UTC (permalink / raw) In article <Pine.BSF.3.96.980301192928.4408A-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: >> A bunch of guys from all over the planet with PhDs in computer science >> designed the language, and somehow they didn't come up with your "better >> idea." Telling, isn't it? If you think it is an improvement, perhaps that >> is because there is knowledge that you don't have. > >A bunch of guys with PhDs from all over the planet think Ada sucks, some >of them are very well respected too. Which PhDs are right? The PhDs that like Ada, of course. :-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: type names (was Re: Child package: private type and IO) 1998-03-01 0:00 ` Matthew Heaney @ 1998-03-03 0:00 ` Ray Blaak 0 siblings, 0 replies; 14+ messages in thread From: Ray Blaak @ 1998-03-03 0:00 UTC (permalink / raw) Whoops! I seem to have touched a nerve. I know what a type is and agree with your (Matthew's) explanation. I know what module is and approve of Ada's separation of namespaces from types. As for finding the style of, for example, Lists.List irritating as compared to List.Object, well, I am not *that* irritated. I am certainly not upset about the names in the standard Ada packages. mheaney@ni.net (Matthew Heaney) writes: > And by the way, while I'm on the subject, a "class" in other languages as > C++, Eiffel, and Java maps to an Ada tagged type. It does NOT map to an > Ada package. A class in these languages defines both a namespace and a type. To map it to Ada one has to bring in both mechanisms. Either one in isolation will not be sufficient. > Of course, a type name should NOT be qualified by a package name. A type > name is a type name, and a package name is a package name. A package name > is NOT a type name, and in no way participates in naming a type. > > A package is a namespace, and serves only to prevent clashes among > similarly named types in an otherwise global namespace. A package > disambiguates type names, but it is itself not a type name. But it is a very common Ada style to qualified names throughout a program. What is the "use clauses are evil" debate all about, after all? And given a qualified naming style, having names read well considering the package name is also important. As for confusing the difference between a module and a type, I don't see the problem. If one writes in a style that dedicates a package for each (main) type, and uses a qualified naming style, then knowing the package *is* important when dealing with a particular type and its operations. I did not make up the P.Object style. I was introduced to it when working on a large air traffic control project. It so happened that I got used to it and now like it. Consider a discussion about a particular object called L: "What kind of object is it?" "It is a list object." "Oh! That means I can do this and that with it." Having the declaration "L : List.Object" is not an unreasonable way to convey this information. > A bunch of guys from all over the planet with PhDs in computer science > designed the language, and somehow they didn't come up with your "better > idea." Telling, isn't it? If you think it is an improvement, perhaps that > is because there is knowledge that you don't have. It is more likely that I have the knowledge but have a different opinion anyway. Come on, people differ! These PhDs argued like crazy during the design phase of Ada, and things will continue to evolve. But so what? My real opinion about all this is not so much that a particular style is objectively better than another, but that any project should use a consistent style, whatever it is. Following the LRM is certainly a good idea as any. Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: type names (was Re: Child package: private type and IO) 1998-03-01 0:00 ` Matthew Heaney 1998-03-01 0:00 ` Brian Rogoff @ 1998-03-04 0:00 ` Fergus Henderson 1998-03-03 0:00 ` Brian Rogoff 1 sibling, 1 reply; 14+ messages in thread From: Fergus Henderson @ 1998-03-04 0:00 UTC (permalink / raw) mheaney@ni.net (Matthew Heaney) writes: >blaak@infomatch.com (Ray Blaak) wrote: > >>>Objects are the memory locations that store a value of a type. >> >>But you are using the word here as a type! (i.e. the set of things that are >>memory locations that store values). > >No. You are confused about what a type is. No, Ray Blaak is correct here. >Let's begin by defining what we mean by a type. A type is defined as "A >set of values, and a set of operations on those values." For example, I >can define a type > >with the name "Integer" > >and the set of values > > ..., -3, -2, -1, 0, 1, 2, 3, ... > >and the set of operations > > +: Integer x Integer -> Integer > -: Integer x Integer -> Integer > *: Integer x Integer -> Integer > /: Integer x Integer -> Integer > =: Integer x Integer -> Boolean > >etc Agreed. Above, you used the word "Object" to refer to a type with the name "Object", with the set of values being the different possible memory locations, and with the set of operations being fetch, store, etc. Below, you assume that "Object" and "Type" are mutually exclusive; this is true in Ada, but there are other languages for which it is not true. >A type refers to the set of values, NOT the objects. An object is a memory >location inside a computer, that stores a value, a value we interpret as >having a certain type. So when we declare an object, > >O : T; > >we're allocating a memory cell, and we're interpreting the value of the >data in that cell as being of type T. The means the memory cell designated >by object O will only contain certain values, and that only certain >operations may be applied to the value in that cell. > >The memory cell designated by object O isn't really interesting. It's the >data in that cell that's interesting. And it's the data in the cell that >"is of type T," not the object itself. No, the object itself "is [an lvalue] of type T". To say otherwise would imply that objects are untyped, that only values are typed, and that it is therefore possible to store a value of any type in a given object. This is true for some untyped languages, but it is not true in Ada. >It is completely wrong to name a type "Object." Well, I don't particularly like this convention much myself; but I think "completely wrong" is overstating the case. >Yes, it's true we often say "Object O has type T," but we really mean "O is >the name of a memory cell containing a value of type T." No. What we really mean is "O has type n<T>", where "n<T>" is a (parametric) type whose operations include "fetch" (syntactically implicit in Ada) and "store" (`:='). "n<T>" might be better named "name<T>", "lvalue<T>", or even "object<T>". >>>A type should be named using a noun phrase, such as >>>type Singly_Linked_List is ...; >> >>I think that style of type names used really depends on if type names are >>qualified with package names or not. > >Of course, a type name should NOT be qualified by a package name. A type >name is a type name, and a package name is a package name. A package name >is NOT a type name, and in no way participates in naming a type. No, a package name surely does participate in naming a type, for the type's fully-qualified name includes the name of the package in which it is contained. >A package is a namespace, and serves only to prevent clashes among >similarly named types in an otherwise global namespace. No, packages also provide encapsulation, not just namespace control. >A package disambiguates type names, but it is itself not a type name. Agreed. >To use a package as part of the type, as in > >package P is > > type Object is ...; >... >end P; > >The_Object : P.Object; > >so that the "real" type name is "P.Object" only confuses the difference >between a module and a type. Nonsense! The package name is P; the type name is P.Object (though it can be abbreviated as Object, in certain contexts). What's there to be confused about? >>Having: >> >> package Linked_List is >> type Linked_List is ... >> end Linked_List; >> >>results in usage like: >> >> Employees : Linked_List.Linked_List; >> >>which I personally find irritating. > >The package is misnamed. A common idiom, and a very OLD idiom in the Ada >community, is to use the plural of the type name as the package name, Well, that doesn't help much -- now the usage is Employees : Linked_Lists.Linked_List; which is still just as ugly. >I'm sorry you find this convention irritating. If so, then you can tell >the language designers that they named the packages > >Ada.Characters >Ada.Interrupts >Ada.Interrupts.Names >Ada.Exceptions >Ada.Numerics >Ada.Streams >Ada.Strings >Interfaces >Interfaces.C.Pointers >Interfaces.C.Strings >System.Address_To_Access_Conversions >System.Storage_Elements >System.Storage_Pools > >incorrectly, and that the names they chose irritate you. It's not a question of "correct" or "incorrect", it's a question of style. The style chosen for the standard library strongly encourages the use of `use', to avoid unnecessary redundancy in names like `Ada.Strings.Unbounded.Unbounded_String'. This is probably not such a bad thing for the standard library, since experienced Ada programmers will know the standard library well; but for more general settings, encouraging the use of `use' may not be such a good idea. Personally, I quite like the style of naming types `T', e.g. `Ada.Strings.Unbounded.T'. >> However a package like: >> >> package Linked_List is >> type Object is ... >> end Linked_List; >> >>results in usage like: >> >> Employees : Linked_List.Object; >> >>which reads better to me. > >It reads better to you because you are confused. You don't understand the >difference between a module and a type. Well, it reads better to me too, and I definitely do understand the difference between a module and a type (and I think Ray Blaak probably does too). >If you don't believe that this is the Ada idiom, [...] I think Ada is big enough for more than one idiom! -- Fergus Henderson | Designing grand concepts is fun; fjh@cs.mu.oz.au | finding nitty little bugs is just work. http://www.cs.mu.oz.au/~fjh | -- Brooks, in "The Mythical Man-Month". PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC 8B 3E 0F 01 E7 5D C4 3F ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: type names (was Re: Child package: private type and IO) 1998-03-04 0:00 ` Fergus Henderson @ 1998-03-03 0:00 ` Brian Rogoff 1998-03-04 0:00 ` John G. Volan 0 siblings, 1 reply; 14+ messages in thread From: Brian Rogoff @ 1998-03-03 0:00 UTC (permalink / raw) Amazing how much this naming style issue comes up here :-). On 4 Mar 1998, Fergus Henderson wrote: > >The package is misnamed. A common idiom, and a very OLD idiom in the Ada > >community, is to use the plural of the type name as the package name, > > Well, that doesn't help much -- now the usage is > > Employees : Linked_Lists.Linked_List; > > which is still just as ugly. FWIW, using the plural package name style I would probably chose either Employees : Linked_Lists.List_Type; or Employees : Linked_Lists.List_T; which may still be just as ugly (at least to Matthew) but makes clear which part of the name is the type name, even in the presence of a use clause. I've yet to determine whether I feel an _Class suffix is also appropriate for access to classwide type; I know I don't like the "_Access" for Stream_Access. > It's not a question of "correct" or "incorrect", it's a question > of style. I couldn't agree more. > The style chosen for the standard library strongly > encourages the use of `use', to avoid unnecessary redundancy in > names like `Ada.Strings.Unbounded.Unbounded_String'. > This is probably not such a bad thing > for the standard library, since experienced Ada programmers > will know the standard library well; but for more general settings, > encouraging the use of `use' may not be such a good idea. Why not? ;-) OK, I shouldn't be provoking the anti-use faction here, but since you can use use in a restricted scope, I don't see why draconian policies on its use are acceptable (SPARK and similar technologies excepted). > Personally, I quite like the style of naming types `T', > e.g. `Ada.Strings.Unbounded.T'. What about when there is more than one type per package? I suppose in many cases (by analogy with inheritance hierarchies) there is really a main type, so you might have Collections.Lists.T; Collections.Lists.T_Iter; ... but I'm interested in reading about other styles that people have found pleasant, so please elaborate. > I think Ada is big enough for more than one idiom! Indeed. -- Brian ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: type names (was Re: Child package: private type and IO) 1998-03-03 0:00 ` Brian Rogoff @ 1998-03-04 0:00 ` John G. Volan 1998-03-05 0:00 ` Case sensitivity [was Re: type names (was Re: Child package: private type and IO)] Anonymous 0 siblings, 1 reply; 14+ messages in thread From: John G. Volan @ 1998-03-04 0:00 UTC (permalink / raw) Brian Rogoff wrote: > > Amazing how much this naming style issue comes up here :-). Indeed. :-) > FWIW, using the plural package name style I would probably chose either > > Employees : Linked_Lists.List_Type; > > or > > Employees : Linked_Lists.List_T; > > which may still be just as ugly (at least to Matthew) but makes clear > which part of the name is the type name, even in the presence of a > use clause. This scheme still doesn't give Ada programmers enough to go on to deal with most real-world programming situations. For instance, it seems to me that there might be other sorts of lists in this program other than just lists of employees (for instance, lists of companies), so it would be unwise to use "List_Type" and "Linked_Lists" for a type and package that only support lists of employees. And the same program might very well make use of other kinds of employee collections than just employee lists (for instance, employee sets or employee queues), so to name a given variable simply "Employees", without conveying whether it is a list or set or queue of employees, is also unwise. Besides, "Employees" might already be the name of a package containing a type called "Employee_Type". I would favor the following convention: Employee_List : Employee_Lists.Employee_List_Type; --*see footnote Employee_Set : Employee_Sets.Employee_Set_Type; Employee_Queue : Employee_Queues.Employee_Queue_Type; Company_List : Company_Lists.Company_List_Type; Company_Set : Company_Sets.Company_Set_Type; If you choose to use "use" (I'm not necessarily endorsing that), then this becomes: Employee_List : Employee_List_Type; Employee_Set : Employee_Set_Type; Employee_Queue : Employee_Queue_Type; Company_List : Company_List_Type; Company_Set : Company_Set_Type; In other words, be "semantically economical" when it comes to naming things: An Ada type, its enclosing package, and all its instance objects, can all be seen as just different manifestations of a single abstract concept. So if you already have a pithy phrase that neatly describes that abstraction (e.g., "employee list") then you shouldn't waste time hunting for synonymous (and possibly less apt) phrases, just for the sake of differentiating these various constructs. Instead, just embed the same pithy phrase in the names of each of these constructs, but find some systematic scheme for "marking" these names to differentiate them. The more mechanical that sceme is, the better, because it means less mental work for the programmer (and for the readers!) For instance (as demonstrated above): (1) Mark the package name by using the plural: e.g. "Employee_Lists". (2) Mark the type name by appending the suffix "_Type": e.g. "Employee_List_Type". (Or you could use "_T" if you must; the important thing is to use your chosen marker consistently.) (3) Reserve the unmarked form for an object name: e.g. "Employee_List". Use this whenever you're in a context where there's no compelling need to distinguish that particular object from any other instance of that type. Usually this means the object is the only instance of that type in that context; often, this is a parameter to a subprogram. (4) When there is a compelling reason to distinguish particular objects (e.g., when you're dealing with more than one instance of the same type in the same context), mark the object names by attaching adjectives that are appropriate to the particular situation: e.g., "Active_Employee_List" versus "Terminated_Employee_List". Note that most object-oriented languages make it somewhat easier than Ada to establish a systematic, semantically-economical naming scheme, for two reasons: (1) The "class" construct merges the roles of both a package and a type, so there are fewer things to name. (2) Other languages tend to be case-sensitive, so capitalization is available as a mechanism for "marking". For instance, instead of having to say: Employee_List : Employee_Lists.Employee_List_Type; in Eiffel you could simply say: employeeList : EmployeeList; and in Java or C++ this would be: EmployeeList employeeList; where "EmployeeList" is the name of a class (=package+type) and "employeeList" is the name of an object. The convention of marking class names with initial uppercase and object names with initial lowercase (and separating words by capitalization rather than underscores) is well-accepted among folks using Smalltalk, C++, Java and Eiffel, so it's become something of an industry standard. (Personally, after working in Java for several months, I've gotten to like this convention. Now I find myself wishing Ada95 had gone the case-sensitive route too... Oops! I can see another religious can of worms opening up again... :-) *Footnote: The above scheme didn't consider the effect of using generics. For example, suppose you have a generic package for linked lists: generic type Item_Type is private; package Lists is type List_Type is ... ... end Lists; And suppose you instantiate this for different item types: package Employee_Lists is new Lists (Item_Type => Employees.Employee_Type); package Company_Lists is new Lists (Item_Type => Companies.Company_Type); Then what you'd have to say is: Employee_List : Employee_Lists.List_Type; Company_List : Company_Lists.List_Type; And you'd be forced to qualify the type names here, even if you used "use". Unfortunately, when you instantiate a generic in Ada, you only get a new package name; you don't get a new *type* name as well. On the other hand, in class-based OO languages that support generic templates, this issue doesn't come up, because class=package+type. For instance, in C++, you could have: typedef List<Employee> EmployeeList; typedef List<Company> CompanyList; ... EmployeeList employeeList; CompanyList companyList; (When they get around to putting generic templates into Java, I anticipate the situation will be similar.) -- Signature volanSignature = new Signature ( /*name: */ "John G. Volan", /*employer: */ "Raytheon Advanced C3I Systems, San Jose", /*workEmail: */ "johnv@ac3i.dseg.ti.com", /*homeEmail: */ "johnvolan@sprintmail.com", /*resumeBlip:*/ "Sun Certified Java Programmer", /*twoCents: */ "Java would be even cooler with Ada95's " + "generics, enumerated types, function types, " + "named parameter passing, etc...", /*disclaimer:*/ "These views not packaged in COM.ti.dseg.ac3i, " + "so loading them throws DontQuoteMeError. :-)" ); ^ permalink raw reply [flat|nested] 14+ messages in thread
* Case sensitivity [was Re: type names (was Re: Child package: private type and IO)] 1998-03-04 0:00 ` John G. Volan @ 1998-03-05 0:00 ` Anonymous 1998-03-05 0:00 ` John G. Volan 0 siblings, 1 reply; 14+ messages in thread From: Anonymous @ 1998-03-05 0:00 UTC (permalink / raw) <6c2r0l$iic$1@madmax.keyway.net> <6cbuat$cg3$1@nnrp1.dejanews.com> <mheaney-ya023680002702982024210001@news.ni.net> <6dcio1$fvo$1@berlin.infomatch.com> <mheaney-ya023680000103981905280001@news.ni.net> <6dhghp$suv$1@mulga.cs.mu.OZ.AU> <Pine.BSF.3.96.980303102557.142A-100000@shell5.ba.best.com> On Wed, 04 Mar 1998 18:19:20 -0800, "John G. Volan" <johnv@ac3i.dseg.ti.com> wrote: > ... > package and a type, so there are fewer things to name. (2) Other > languages tend to be case-sensitive, so capitalization is available as a > mechanism for "marking". For instance, instead of having to say: > ... Let's see, I've used FORTRAN COBOL APL Pascal BASIC Databus MOBOL-2 Several assemblers C LISP SNOBOL Ada How many of these are case sensitive? One. So my experience is that "other languages" (than Ada) tend not to be case sensitive. Jeff Carter PGP:1024/440FBE21 My real e-mail address: ( carter @ innocon . com ) "You brightly-colored, mealy-templed, cranberry-smelling, electric donkey-bottom biters." Monty Python & the Holy Grail Posted with Spam Hater - see http://www.compulink.co.uk/~net-services/spam/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Case sensitivity [was Re: type names (was Re: Child package: private type and IO)] 1998-03-05 0:00 ` Case sensitivity [was Re: type names (was Re: Child package: private type and IO)] Anonymous @ 1998-03-05 0:00 ` John G. Volan 0 siblings, 0 replies; 14+ messages in thread From: John G. Volan @ 1998-03-05 0:00 UTC (permalink / raw) > On Wed, 04 Mar 1998 18:19:20 -0800, "John G. Volan" > <johnv@ac3i.dseg.ti.com> wrote: > > > ... > > package and a type, so there are fewer things to name. (2) Other > > languages tend to be case-sensitive, so capitalization is available as a > > mechanism for "marking". For instance, instead of having to say: > > ... Note that in the context of this paragraph it was pretty clear that I was talking about other *object-oriented* languages. Perhaps I should have fully-qualified this sentence as: "The most popular modern class-based object-oriented languages tend to be ..." :-) Jeff Carter responded: > > Let's see, I've used > > FORTRAN > COBOL > APL > Pascal > BASIC > Databus > MOBOL-2 > Several assemblers > C > LISP > SNOBOL > Ada > > How many of these are case sensitive? One. So my experience is that > "other languages" (than Ada) tend not to be case sensitive. That's true, but out of the above set (to my knowledge) only Ada(95) is a fully object-oriented language, per se. Okay, I'll give you Pascal if you mean Object Pascal, and Lisp too if you mean CLOS, and COBOL as well if you mean the recent object-oriented incarnation. (Not sure about BASIC -- does e.g. Visual Basic do objects and classes? Never heard of MOBOL-2, what is that?) So, of the major object-oriented contenders out there we have: Case-Sensitive Case-Insensitive -------------- ---------------- Smalltalk Ada Eiffel Common Lisp Object System C++ Object Cobol (is that the name?) Objective C Object Pascal Java Modula-2/3 A 60%-40% split in favor of case-sensitivity. Hmm, not a landslide victory ... but how useful and/or scientific is it to just list names of languages? All that speaks to is the level of popularity of case-sensitivity among the *designers* of object-oriented programming languages. I'd wager if you did a scientific survey of object-oriented *programmers* and weighted the scores by volume of actual *usage* of these languages, the case :-) for case-sensitivity's popularity would be pretty strong. At any rate, my main point is not whether case-sensitivity is more popular among object-oriented programmers than case-insensitivity (even although I believe that to be true). And I'm not trying to make any particular religious judgment about whether case-sensitivity is "better" based solely on its popularity. My point is simply that when case-sensitivity *is* available in an object-oriented language, it somewhat reduces the mental workload for the authors and readers of code: They don't need to resort to elaborate schemes of agglutinating special suffixes or prefixes just to distinguish object names from class/type names. Capitalization standards alone can provide an adequate marking mechanism (at least to cover the object-vs-class distinction). -- Signature volanSignature = new Signature ( /*name: */ "John G. Volan", /*employer: */ "Raytheon Advanced C3I Systems, San Jose", /*workEmail: */ "johnv@ac3i.dseg.ti.com", /*homeEmail: */ "johnvolan@sprintmail.com", /*selfPlug: */ "Sun Certified Java Programmer", /*twoCents: */ "Java would be even cooler with Ada95's " + "generics, enumerated types, function types, " + "named parameter passing, etc...", /*disclaimer:*/ "These views not packaged in COM.ti.dseg.ac3i, " + "so loading them throws DontQuoteMeError. :-)" ); ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~1998-03-05 0:00 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-02-14 0:00 Child package: private type and IO johnjohn 1998-02-16 0:00 ` Tom Moran 1998-02-17 0:00 ` sparre 1998-02-27 0:00 ` Matthew Heaney 1998-03-01 0:00 ` type names (was Re: Child package: private type and IO) Ray Blaak 1998-03-01 0:00 ` Matthew Heaney 1998-03-01 0:00 ` Brian Rogoff 1998-03-01 0:00 ` Matthew Heaney 1998-03-03 0:00 ` Ray Blaak 1998-03-04 0:00 ` Fergus Henderson 1998-03-03 0:00 ` Brian Rogoff 1998-03-04 0:00 ` John G. Volan 1998-03-05 0:00 ` Case sensitivity [was Re: type names (was Re: Child package: private type and IO)] Anonymous 1998-03-05 0:00 ` John G. Volan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox