From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,449b3383afc55069 X-Google-Attributes: gid103376,public From: fjh@cs.mu.OZ.AU (Fergus Henderson) Subject: Re: type names (was Re: Child package: private type and IO) Date: 1998/03/04 Message-ID: <6dhghp$suv$1@mulga.cs.mu.OZ.AU> X-Deja-AN: 330476441 References: <6c2r0l$iic$1@madmax.keyway.net> <6cbuat$cg3$1@nnrp1.dejanews.com> <6dcio1$fvo$1@berlin.infomatch.com> Organization: Computer Science, The University of Melbourne Newsgroups: comp.lang.ada Date: 1998-03-04T00:00:00+00:00 List-Id: 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", where "n" is a (parametric) type whose operations include "fetch" (syntactically implicit in Ada) and "store" (`:='). "n" might be better named "name", "lvalue", or even "object". >>>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