* Naming of Tagged Types and Associated Packages @ 1998-07-16 0:00 taashlo 1998-07-25 0:00 ` Matthew Heaney 0 siblings, 1 reply; 138+ messages in thread From: taashlo @ 1998-07-16 0:00 UTC (permalink / raw) In the _Ada 95 Quality and Style_ guidelines, section 3.2.4 "Naming of Tagged Types and Associated Packages", there are two instantions. One integrates the use of object-oriented features. The other highlights the use of object-oriented features. Could somebody please give a summary of the strengths and weaknesses of each? And maybe an example of where one convention would be more appropriate than the other? Thanks, Tad Ashlock <taashlo@sandia.gov> ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-16 0:00 Naming of Tagged Types and Associated Packages taashlo @ 1998-07-25 0:00 ` Matthew Heaney 1998-07-25 0:00 ` Jean-Pierre Rosen 0 siblings, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-07-25 0:00 UTC (permalink / raw) taashlo@sandia.SPAMFREE.gov writes: > In the _Ada 95 Quality and Style_ guidelines, section 3.2.4 "Naming of > Tagged Types and Associated Packages", there are two instantions. One > integrates the use of object-oriented features. The other highlights > the use of object-oriented features. Could somebody please give a > summary of the strengths and weaknesses of each? And maybe an example > of where one convention would be more appropriate than the other? Here are a few ideas: 1) Name the package using the plural of the (tagged on non-tagged) type it exports: package Bank_Accounts is type Bank_Account is tagged limited private; ... end Bank_Accounts; If you export more the one ADT, then the package name should conver the theme of the types; it may be just the plural of the root of a type hierarchy: package Computer_Equipment is type Root_Equipment is tagged private; type CD_ROM is new Root_Equipment with private; type Floppy_Disk is new Root_Equipment with private; type Hard_Drive is new Root_Equipment with private; ... end Computer_Equipment; 2) Name the type with a noun phrase: type Root_Equipment is tagged private; type Bank_Account is tagged private; type File_Type is private; 3) If you have a type hierarchy, and you want to put the derived types in different package, then put the types in child packages of the package that declares the root type. Name the child packages using the adjective used to name the derived type: package Bank_Accounts.Checking is type Checking_Account is new Bank_Account with private; ... package Bank_Accounts.Savings is type Savings_Account is new Bank_Account with private; ... And whatever you do, please do NOT name a type "Object" or "Instance". This is a sure sign of confusion about the difference between a module and a type, which are orthogonal language features in Ada. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-25 0:00 ` Matthew Heaney @ 1998-07-25 0:00 ` Jean-Pierre Rosen 1998-07-25 0:00 ` Brian Rogoff 1998-07-26 0:00 ` Matthew Heaney 0 siblings, 2 replies; 138+ messages in thread From: Jean-Pierre Rosen @ 1998-07-25 0:00 UTC (permalink / raw) >And whatever you do, please do NOT name a type "Object" or "Instance". >This is a sure sign of confusion about the difference between a module >and a type, which are orthogonal language features in Ada. > Well, since I was the first one to publish that notation (I do not claim to be the first one who thought of it), let me follow up. We are talking about classes here, and a class is an encapsulation of a data type together with operations. In that sense, a type is certainly not a class, since it addresses only the data-type part of a class. Rather, a class is a certain way of using a package, to declare a type and associated operations (methods), and nothing else. Of course, there are other ways of using packages: packages, as well as types and nearly any other feature of the language, are building blocks that allow you to create various paradigms depending on the way you put them together. However, if you agree that such a package corresponds to what is called a class in OO languages, then it makes sense to name the package, not the type, after the entity you want to represent. Now the package may declare some utility types in addition to the "main" type; it makes sense to have some notation to distinguish this main type. "Instance" or "Object" look nice in a declaration like: My_Account: Bank_Account.Instance; but this is not the main point. The really important point is to use the same name for the main type of every "class package", because it allows you to have a uniform convention, whether you're using a declared package or an instantiation of a generic. And remember that generic are very important, since they provide multiple inheritance (or to be more politically correct: because they fulfill the needs that are fulfilled by multiple inheritance in other languages ;-) A full discussion of these issues can be found in the paper "a naming convention for classes in Ada 9X" which appeared in Ada Letters by the end of 94 (sorry, I don't have the exact reference at hand). ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-25 0:00 ` Jean-Pierre Rosen @ 1998-07-25 0:00 ` Brian Rogoff 1998-07-26 0:00 ` Matthew Heaney 1998-07-26 0:00 ` Matthew Heaney 1 sibling, 1 reply; 138+ messages in thread From: Brian Rogoff @ 1998-07-25 0:00 UTC (permalink / raw) On Sat, 25 Jul 1998, Jean-Pierre Rosen wrote: > >And whatever you do, please do NOT name a type "Object" or "Instance". > >This is a sure sign of confusion about the difference between a module > >and a type, which are orthogonal language features in Ada. > > > Well, since I was the first one to publish that notation (I do not claim to > be the first one who thought of it), let me follow up. > > We are talking about classes here, and a class is an encapsulation of a data > type together with operations. In that sense, a type is certainly not a > class, since it addresses only the data-type part of a class. > > Rather, a class is a certain way of using a package, to declare a type and > associated operations (methods), and nothing else. Of course, there are > other ways of using packages: packages, as well as types and nearly any > other feature of the language, are building blocks that allow you to create > various paradigms depending on the way you put them together. > > However, if you agree that such a package corresponds to what is called a > class in OO languages, then it makes sense to name the package, not the > type, after the entity you want to represent. Now the package may declare > some utility types in addition to the "main" type; it makes sense to have > some notation to distinguish this main type. "Instance" or "Object" look > nice in a declaration like: > My_Account: Bank_Account.Instance; I could follow your reasoning up to this point, but I think that it is a mistake to name a *type* something like Instance or Object, since an instance is more like a variable. If you want to adhere to the module = class style of OOP, where there is one main type in the package, then the Modula-3 convention of using the name "T" for the type, mentioned here previously by Fergus Henderson, seems more appropriate. The name Object or Instance should only appear on the left hand side of the declaration. Of course, this assumes that you are an orthodox OOer who doesn't coencapsulate types... -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-25 0:00 ` Brian Rogoff @ 1998-07-26 0:00 ` Matthew Heaney 0 siblings, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-07-26 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> writes: > The name > Object or Instance should only appear on the left hand side of the > declaration. An excellent point. To call a type "Object" is thoroughly confusing, because an object is the thing that is an instance of the type. There is a long tradition in the Ada community of using the expression O : T; as shorthand when discussing programming issues. I can't remember anyone using the expression The_O : P.O; as "short"hand. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-25 0:00 ` Jean-Pierre Rosen 1998-07-25 0:00 ` Brian Rogoff @ 1998-07-26 0:00 ` Matthew Heaney 1998-07-26 0:00 ` nabbasi ` (2 more replies) 1 sibling, 3 replies; 138+ messages in thread From: Matthew Heaney @ 1998-07-26 0:00 UTC (permalink / raw) "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > >And whatever you do, please do NOT name a type "Object" or "Instance". > >This is a sure sign of confusion about the difference between a module > >and a type, which are orthogonal language features in Ada. > > > Well, since I was the first one to publish that notation (I do not claim to > be the first one who thought of it), let me follow up. Jean-Pierre: I loved your other article in ACM, "What Orientation Should Ada Objects Take," but "didn't care for" the one you mention above, in Ada Letters. > We are talking about classes here, and a class is an encapsulation of a data > type together with operations. In that sense, a type is certainly not a > class, since it addresses only the data-type part of a class. This is wrong. The defination of a type has _always_ been "data + operations." The term "class" to designate a type is an unfortunate mistake make by the designers of Simula. > Rather, a class is a certain way of using a package, to declare a type and > associated operations (methods), and nothing else. I prefer to refer to such a package as "a package that exports an abstract data type" or just "an ADT package." To refer to such a package as a "class" is incorrect, because a package is a module, not a type. The use of the convention "P.Instance" to refer to the "real" type name is very misguided, because it's as if you're trying to make a package into a type, which it is not. If the language designers had wanted module and type to be the same, then they would have designed the language that way, and you wouldn't need to say "type Instance is ..." at all. You might not like it, especially since this is probably perceived as idiosyncratic by programmers who have used other object-oriented languages (in which module and type are the same), but that's just the way it is. No coding convention is going to change this. > However, if you agree that such a package corresponds to what is called a > class in OO languages, then it makes sense to name the package, not the > type, after the entity you want to represent. No, I do most certainly do NOT agree that a package is equivalent to a class in other languages. A class is a type, and we already have types in Ada. All a package does in Ada is to demarcate which operations of the type are primitive. The "real" name of the type is the identifier used in the type declaration, never the name of the enclosing package. > Now the package may declare > some utility types in addition to the "main" type; it makes sense to have > some notation to distinguish this main type. "Instance" or "Object" look > nice in a declaration like: > My_Account: Bank_Account.Instance; You may think it looks nice, but I read this and think "Je crois qu'elle est laide." Why not just My_Account: Bank_Account; You know, the way the language designers intended? > but this is not the main point. The really important point is to use the > same name for the main type of every "class package", because it allows you > to have a uniform convention I don't understand what you mean. We've been calling files File_Type for almost 20 years, and so far no one has complained. > A full discussion of these issues can be found in the paper "a naming > convention for classes in Ada 9X" which appeared in Ada Letters by the end > of 94 (sorry, I don't have the exact reference at hand). We obviously have philosophical differences about the nature of a type. Oh, well. I'll be in Paris in September: perhaps we can meet at a cafe to discuss it more over "une pression"! ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-26 0:00 ` Matthew Heaney @ 1998-07-26 0:00 ` nabbasi 1998-07-26 0:00 ` Matthew Heaney 1998-07-26 0:00 ` Robert Dewar 1998-07-27 0:00 ` Jean-Pierre Rosen 1998-07-27 0:00 ` dennison 2 siblings, 2 replies; 138+ messages in thread From: nabbasi @ 1998-07-26 0:00 UTC (permalink / raw) offcourse a type is defined as set of values and set of operations. I find it very hard in Ada to visualize an tagged object. but I can easily visulaize a class object in Java or C++ becuase the class construct makes it easy for me to do that. when I used Ada, I use it as an object-based (as opposed to object-oriented) langauge, which is what Ada was originally designed as, I do not use Ada for its OO features. I like Ada as a procedural/object based, and for that it is great. plus I think all the OO/inhertence stuff is way overrated any way. abstraction, data hiding, sepration of interfaces and implementaions, strong typing, generics, good exception, good build-in tasking model, and all that good stuff is good enough for me. If I want to do heavy/pure OO stuff, I would not use Ada, just becuase I am not used to the OO ways of Ada, it just too different from all the other OO languages out there (different in how its OO features are reprsented offcourse, the semactics are the same, but language representation (lexical structure) is very important I think becuase it affect how one thinks and visualize things), and in that the class structure is more natural than tagged records + procedures that takes paramters or returns paramters of types of that record. my 2 cents. Nasser ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-26 0:00 ` nabbasi @ 1998-07-26 0:00 ` Matthew Heaney 1998-07-26 0:00 ` Robert Dewar 1 sibling, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-07-26 0:00 UTC (permalink / raw) nabbasi@earthlink.net writes: > offcourse a type is defined as set of values and set of operations. Yes. > I find it very hard in Ada to visualize an tagged object. but I can > easily visulaize a class object in Java or C++ becuase the class construct > makes it easy for me to do that. I don't understand your problem: type T is tagged private; is exactly equivalent to class T {... in C++. If the features of a type aren't obvious from reading the text of an Ada program, then something is probably wrong with the program, not the language itself. > when I used Ada, I use it as an object-based (as opposed to object-oriented) > langauge, which is what Ada was originally designed as, I do not use Ada for > its OO features. I like Ada as a procedural/object based, and for that it > is great. plus I think all the OO/inhertence stuff is way overrated > any way. Pete Wegner has done a lot of damage, I'm afraid. His classification of Ada 83 as object-based is incorrect. Ada 83 is properly classified as a type-based language (his term was "class-based," but I want to stick to Ada terminology). The addition of tagged types in Ada 95 is good, but it doesn't change implementation techniques that much from Ada 83, because you should already be using type-based abstractions where that makes sense. (I give some advice for knowing when to use a package vs when to use a type in the design patterns archives at the ACM website. Search for "singleton".). I agree, by the way, that inheritence as a re-use mechanism is way overrated. All it does is increase coupling, and make (deep) hierarchies too sensitive to changes in the classes near the root. Ada provides composition mechanisms that don't require inheritence. This means that if you're building deep inheritance hierarchies in Ada 95 ("deep" defined as more than 2 or 3 levels), then you're probably doing something wrong. Any normal system is going to require changes as it is built, so you'll have the compile-the-universe problem every time there's a change. > abstraction, data hiding, sepration of interfaces and implementaions, strong > typing, generics, good exception, good build-in tasking model, and all > that good stuff is good enough for me. If I want to do heavy/pure > OO stuff, I would not use Ada, just becuase I am not used to the OO > ways of Ada, it just too different from all the other OO languages > out there (different in how its OO features are reprsented offcourse, > the semactics are the same, but language representation (lexical > structure) is very important I think becuase it affect how one thinks > and visualize things), and in that the class structure is more natural than > tagged records + procedures that takes paramters or returns paramters > of types of that record. How you do it in Ada 95 is not much different from how you do it in Ada 83. If you think Ada 95 is "too different" from other oo languages, then you must think the same think about Ada 83, right? The Ada way has some advantages, because I can say this: if O1 = O2 then ...; instead of the klunky if O1.Is_Equal (O2) the ...; ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-26 0:00 ` nabbasi 1998-07-26 0:00 ` Matthew Heaney @ 1998-07-26 0:00 ` Robert Dewar 1 sibling, 0 replies; 138+ messages in thread From: Robert Dewar @ 1998-07-26 0:00 UTC (permalink / raw) Nasser said <<abstraction, data hiding, sepration of interfaces and implementaions, strong typing, generics, good exception, good build-in tasking model, and all that good stuff is good enough for me. If I want to do heavy/pure OO stuff, I would not use Ada, just becuase I am not used to the OO ways of Ada, it just too different from all the other OO languages out there (different in how its OO features are reprsented offcourse, the semactics are the same, but language representation (lexical structure) is very important I think becuase it affect how one thinks and visualize things), and in that the class structure is more natural than tagged records + procedures that takes paramters or returns paramters of types of that record. >> Note that in the above, you note that you are not used to the OO ways of Ada, and then go on to make some comments that really would only ve valid if you *did* have the necessary familiarity. In fact once you know these features well, and are "use" to them, you will find that (a) they are quite natural to use, and (b) it is rather trivial to make the syntactic transition for cases where there is a direct correspondence. Of course in the cases where there is NOT a direct correspondence (e.g. the built in MI in C++, or the generalization of multiple arguments and return types for dispatching in Ada), then the transition is of course harder. Actually there are many "pure" OO abstractions for which the Ada approach, which avoids the nasty binary operator problem in C++ is very much more straightforward. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-26 0:00 ` Matthew Heaney 1998-07-26 0:00 ` nabbasi @ 1998-07-27 0:00 ` Jean-Pierre Rosen 1998-07-28 0:00 ` Matthew Heaney 1998-07-29 0:00 ` Robert I. Eachus 1998-07-27 0:00 ` dennison 2 siblings, 2 replies; 138+ messages in thread From: Jean-Pierre Rosen @ 1998-07-27 0:00 UTC (permalink / raw) (In this discussion, we are discussing how to use classification in Ada; whether classification in itself is a good thing is a different issue; and I don't think I can be accused of being an inheritance fan ;-) Matthew Heaney a �crit dans le message ... >"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > >> We are talking about classes here, and a class is an encapsulation of a data >> type together with operations. In that sense, a type is certainly not a >> class, since it addresses only the data-type part of a class. > >This is wrong. The defination of a type has _always_ been "data + >operations." The term "class" to designate a type is an unfortunate >mistake make by the designers of Simula. The *type* definition by itself only defines the data. It is the fact that some operations are defined in the same *package specification* as the type that makes them bound to the type. Yes, a package is an encapsulation mechanism; it is the encapsulation that transforms a type + some operations in a "class". >The use of the convention "P.Instance" to refer to the "real" type name >is very misguided, because it's as if you're trying to make a package >into a type, which it is not. In this case, the package is the "class". >> Now the package may declare >> some utility types in addition to the "main" type; it makes sense to have >> some notation to distinguish this main type. "Instance" or "Object" look >> nice in a declaration like: >> My_Account: Bank_Account.Instance; > >You may think it looks nice, but I read this and think "Je crois qu'elle >est laide." Why not just > My_Account: Bank_Account; This is a very important issue in naming, which is much more general than even this discussion. Should a type name be descriptive of what the *type* is, or should it be descriptive of what the *variables* are ? In other terms, when you read: A : T; do you read it as "A is of type T" or as "A is a T" ? In the second case, my notation would directly read "My_Account is an instance of Bank_Account". Other people may read it differently. However, If I personnaly prefer naming related to variables rather than type, it is because of a general principle that the client should be favoured against the server. In this case, a type is defined once, and used very often. I therefore prefer the name which is more descriptive in the general case. But this certainly a matter of opinions. >> but this is not the main point. The really important point is to use the >> same name for the main type of every "class package", because it allows you >> to have a uniform convention > >I don't understand what you mean. We've been calling files File_Type >for almost 20 years, and so far no one has complained. Then, you miss the real issue. Actually, I wrote a book some times ago (in French, and I still don't have a publisher for the english translation, anybody's listening? ;-), and I stumbled into the problem of a consistent notation for generics. That was the main triggering reason for that notation. Since you didn't seem to keep you backlog of Ada Letters, let me summarize the issue. Assume (your notation): package Bank_Accounts is type Bank_Account is tagged... -- operations .... end Bank_Account; Assume that some bank accounts are "privileged" in some sense. You want a generic to allow this on any bank_account: generic with old_account is new Bank_Account with private; package Privileged_Account is type ??? is new old_Account with private; --- other operations end Privileged_Account; The trouble is that when you instantiate the generic, you can choose the name of the new package, but not the names of what is declared inside, and especially the type. I you want the type name to carry the useful information, the type name should change with each instantiation! With my notation, the package name carries the useful information, and therefore the same convention can be used for packages obtained by generic instantiations and for regular packages. >We obviously have philosophical differences about the nature of a type. >Oh, well. I'll be in Paris in September: perhaps we can meet at a cafe >to discuss it more over "une pression"! I'd be glad to. Just drop me a note when you know when you are there. -- ---------------------------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://perso.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-27 0:00 ` Jean-Pierre Rosen @ 1998-07-28 0:00 ` Matthew Heaney 1998-07-28 0:00 ` Jean-Pierre Rosen 1998-07-29 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-07-28 0:00 UTC (permalink / raw) "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > The *type* definition by itself only defines the data. It is the fact that > some operations are defined in the same *package specification* as the type > that makes them bound to the type. Yes, a package is an encapsulation > mechanism; it is the encapsulation that transforms a type + some operations > in a "class". When I think of "type," I don't just think of the statement type T is ...; I think of "type" as 1) The name of the type, introduced by a type declaration of the form "type T is ..." 2) The primitive operations of the type, which are the subprograms that take the type named T as a parameter, and are declared in the same package as the type declaration. I do not equate "type" with the statement "type T is ...", and that seems to be where you and I part ways. A type is more than that, as it comprises a name, some data, and some operations. You call this thing a "class," but I prefer to stick to Ada terminology. The Ada statement "type T is ..." tells me the name (and ultimately the representation), but that is not equivalent to a "type"; it isn't enough to be a type. > >The use of the convention "P.Instance" to refer to the "real" type name > >is very misguided, because it's as if you're trying to make a package > >into a type, which it is not. > In this case, the package is the "class". I don't make a distinction between "type" and "class." The Ada term is for type is "type," and the term "class" means "family of types." Again, let's go back to the RM: Text_IO.File_Type is not called File.Instance Ada.Strings.Unbounded.Unbounded_String is not called Ada.Strings.Unbounded_String.Instance Ada.Tags.Tag is not called Ada.Tag.Instance System.Storage_Elements.Storage_Element is not called System.Storage_Element.Instance Why don't Ada programmers like to do what's in the RM? > >> Now the package may declare > >> some utility types in addition to the "main" type; it makes sense to have > >> some notation to distinguish this main type. "Instance" or "Object" look > >> nice in a declaration like: > >> My_Account: Bank_Account.Instance; > > > >You may think it looks nice, but I read this and think "Je crois qu'elle > >est laide." Why not just > > My_Account: Bank_Account; > > This is a very important issue in naming, which is much more general than > even this discussion. > Should a type name be descriptive of what the *type* is, or should it be > descriptive of what the *variables* are ? > In other terms, when you read: > A : T; > do you read it as "A is of type T" or as "A is a T" ? Both. Because there is no difference. > In the second case, my notation would directly read "My_Account is an > instance of Bank_Account". When I see the declaration My_Account : Bank_Account; I think "My_Account is an instance of Bank_Account." How else would you interpret it? > Other people may read it differently. I have to believe you that there are "other people" who read it differently, but it seems pretty obvious to me that the declaration O : T; means "Object O is an instance of type T." If these people are that confused about the nature of a declaration, then I'm not sure a naming convention is going to be enough to end their confusion. > Then, you miss the real issue. Actually, I wrote a book some times ago (in > French, and I still don't have a publisher for the english translation, > anybody's listening? ;-), and I stumbled into the problem of a consistent > notation for generics. That was the main triggering reason for that > notation. Since you didn't seem to keep you backlog of Ada Letters, let me > summarize the issue. > > Assume (your notation): > package Bank_Accounts is > type Bank_Account is tagged... > -- operations .... > end Bank_Account; > > Assume that some bank accounts are "privileged" in some sense. You want a > generic to allow this on any bank_account: > generic > with old_account is new Bank_Account with private; > package Privileged_Account is > type ??? is new old_Account with private; > --- other operations > end Privileged_Account; What's wrong with the convention generic type Account_Type is new Bank_Account with private; package Privileged_Mixin is type Privileged_Account is new Account_Type with private; ... end Privileged_Mixin; > The trouble is that when you instantiate the generic, you can choose the > name of the new package, but not the names of what is declared inside, and > especially the type. I you want the type name to carry the useful > information, the type name should change with each instantiation! With my > notation, the package name carries the useful information, and therefore the > same convention can be used for packages obtained by generic instantiations > and for regular packages. I suppose you could just do another local type derivation, or declare a local subtype. This isn't a big issue for me. I'm happy enough to be able to determine the characteristics of the type once, at point of instantiation, rather than being reminded every object declaration. > >We obviously have philosophical differences about the nature of a type. > >Oh, well. I'll be in Paris in September: perhaps we can meet at a cafe > >to discuss it more over "une pression"! > I'd be glad to. Just drop me a note when you know when you are there. Oui, d'accord! ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` Matthew Heaney @ 1998-07-28 0:00 ` Jean-Pierre Rosen 1998-07-28 0:00 ` dennison 0 siblings, 1 reply; 138+ messages in thread From: Jean-Pierre Rosen @ 1998-07-28 0:00 UTC (permalink / raw) Matthew Heaney a �crit dans le message ... >"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: >[...] >When I think of "type," I don't just think of the statement > > type T is ...; > >I think of "type" as > >1) The name of the type, introduced by a type declaration of the form >"type T is ..." > >2) The primitive operations of the type, which are the subprograms that >take the type named T as a parameter, and are declared in the same >package as the type declaration. Agreed, but this happens ONLY if the type and associated "methods" (primitive operations) are declared in the same package. Therefore, it's the package that turns a "type" into a "class". >I don't make a distinction between "type" and "class." The Ada term is >for type is "type," and the term "class" means "family of types." In this discussion, I take "class" with the conventional meaning of the OOP world. The nice thing with Ada is that its building blocks approach allows you to build various paradigms, and we are talking here about one such special paradigm. Whether naming it "OOP" and using "class" is a good idea is another issue... >Again, let's go back to the RM: > >Text_IO.File_Type > is not called File.Instance > >Ada.Strings.Unbounded.Unbounded_String > is not called Ada.Strings.Unbounded_String.Instance > >Ada.Tags.Tag > is not called Ada.Tag.Instance > >System.Storage_Elements.Storage_Element > is not called System.Storage_Element.Instance I responded to that in an other message... >What's wrong with the convention > >generic > type Account_Type is new Bank_Account with private; >package Privileged_Mixin is > > type Privileged_Account is new Account_Type with private; >... >end Privileged_Mixin; When you instantiate the package, all types will be named "Privileged_Account". Agreed, in this example it is not too bad, but think for example of a package that adds persistency to any tagged type: generic type Origin is tagged private; package Persistence is type Persistent is new Origin with private; ... end Persistence; Then all types to which you add persistency will be called simply "Persistent". Now, you'll tell me that it won't be a problem, since you'll use full notation. But how will you name the package ? "Persistent_Account" ? That would give Persistent_Account.Persistent. Not really pretty. And what if you have a bank account which is both Persistent and Privileged ? Depending on the order of instantiation, you would end up with either Persistent_Privileged_Bank_Account.Persistent or Persistent_Privileged_Bank_Account.Privileged_Account. This would give a special importance to the one which is instantiated last... Once again, if you don't like the name "instance", take something else, but the idea is to have a single, *neutral* name for the main type, in order to have a consistant and uniform notation. >I suppose you could just do another local type derivation, or declare a >local subtype. This was my idea when I first studied the issue, and my paper discusses why it does not work. Please have a look at it. If you don't have an archive of Ada Letters, just drop me a mail telling your preferred format, and I'll be happy to send it to you (if others in this newsgroup also want a copy, they are also welcome :-) -- ---------------------------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://perso.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` Jean-Pierre Rosen @ 1998-07-28 0:00 ` dennison 1998-07-29 0:00 ` Jean-Pierre Rosen 0 siblings, 1 reply; 138+ messages in thread From: dennison @ 1998-07-28 0:00 UTC (permalink / raw) In article <6pk3jh$gpm$2@platane.wanadoo.fr>, "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote: > This was my idea when I first studied the issue, and my paper discusses why > it does not work. Please have a look at it. If you don't have an archive of > Ada Letters, just drop me a mail telling your preferred format, and I'll be > happy to send it to you (if others in this newsgroup also want a copy, they > are also welcome :-) You could just post it here. Or does that break an agreement with Ada Letters? T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` dennison @ 1998-07-29 0:00 ` Jean-Pierre Rosen 1998-07-29 0:00 ` dennison 0 siblings, 1 reply; 138+ messages in thread From: Jean-Pierre Rosen @ 1998-07-29 0:00 UTC (permalink / raw) dennison@telepath.com a �crit dans le message <6pkoir$sh6$1@nnrp1.dejanews.com>... >In article <6pk3jh$gpm$2@platane.wanadoo.fr>, > "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote: > >> This was my idea when I first studied the issue, and my paper discusses why >> it does not work. Please have a look at it. If you don't have an archive of >> Ada Letters, just drop me a mail telling your preferred format, and I'll be >> happy to send it to you (if others in this newsgroup also want a copy, they >> are also welcome :-) > >You could just post it here. Or does that break an agreement with Ada Letters? > OK, it is available as http://perso.wanadoo.fr/adalog/naming9x.zip It is a zipped file that contains naming9x.doc (word6 format) and naming9x.ps (PostScript) I don't think there is any copyright issue, AFAIK Ada-Letters allows free reprints of papers. -- ---------------------------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://perso.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-29 0:00 ` Jean-Pierre Rosen @ 1998-07-29 0:00 ` dennison 1998-07-29 0:00 ` Jean-Pierre Rosen 0 siblings, 1 reply; 138+ messages in thread From: dennison @ 1998-07-29 0:00 UTC (permalink / raw) In article <6pmrkd$5v9$1@platane.wanadoo.fr>, "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote: > OK, it is available as http://perso.wanadoo.fr/adalog/naming9x.zip > It is a zipped file that contains naming9x.doc (word6 format) and > naming9x.ps (PostScript) 27K is mighty small for a Zip file :-). It looks like a large part of the original rationale assumes the need for using generics to provide MI-like facilities to specific child classes of a class. Folks on c.l.a who don't like "Instance" on account of it confusing the issue of what's an object and what's a type, ought to really dislike this: "By the same token, the declaration of the main type is always followed by the declaration of a subtype for the corresponding class wide type; this subtype is always named "class"." So we're using a package to implement a class. But it contains a type named "Class". But "Class" isn't actually full type. Its a subtype declared using the declaration of "Instance", which isn't actually an Instance in the OO-sense but a type. %-( I'm not entirely satisfied with this approach. To me it breaks the fundamental principle that identifiers should be named to describe their metaobject. Instance may be used to create instances, but it is *not* itself an instance (in the OO sense). But neither is it a class in and of itself. It takes the operations in the package and the type to make up a class. But its a whole lot easier to be a critic than a creator. I have yet to think up or see anything better. T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-29 0:00 ` dennison @ 1998-07-29 0:00 ` Jean-Pierre Rosen 1998-07-30 0:00 ` dennison 0 siblings, 1 reply; 138+ messages in thread From: Jean-Pierre Rosen @ 1998-07-29 0:00 UTC (permalink / raw) dennison@telepath.com a �crit dans le message <6pnfkv$qkg$1@nnrp1.dejanews.com>... >In article <6pmrkd$5v9$1@platane.wanadoo.fr>, > "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote: >> OK, it is available as http://perso.wanadoo.fr/adalog/naming9x.zip >> It is a zipped file that contains naming9x.doc (word6 format) and >> naming9x.ps (PostScript) > >27K is mighty small for a Zip file :-). > >It looks like a large part of the original rationale assumes the need for >using generics to provide MI-like facilities to specific child classes of a >class. > >Folks on c.l.a who don't like "Instance" on account of it confusing the issue >of what's an object and what's a type, ought to really dislike this: > >"By the same token, the declaration of the main type is always followed by >the declaration of a subtype for the corresponding class wide type; this >subtype is always named "class"." > >So we're using a package to implement a class. But it contains a type named >"Class". But "Class" isn't actually full type. Its a subtype declared using >the declaration of "Instance", which isn't actually an Instance in the >OO-sense but a type. %-( I appreciate the humour, but it is technically inaccurate. Class *is* a full type, because Instance'class is not the same *type* as Instance. It is even called a "class-wide type", to justify calling it "Class"... OK, I use a subtype to replace a renaming. Note that without this subtype, the class wide type would be called Instance'class, which even I find ugly ;-) >I'm not entirely satisfied with this approach. To me it breaks the fundamental >principle that identifiers should be named to describe their metaobject. >Instance may be used to create instances, but it is *not* itself an instance >(in the OO sense). But neither is it a class in and of itself. It takes the >operations in the package and the type to make up a class. Let me explain once again my position (and I understand perfectly why others may not agree on this). The only use of a type is to declare variables, constants, and formal parameters (these three categories are globally called "objects" in the RM, but I didn't dare using that term in the context of this discussion...). In a client-server model, I tend to favour the client against the server; in this context, it means that I choose a name that maximizes readability of the *variable declaration*, not of the *type declaration*. Given this, I consider that: An_Account : Bank_Account.Instance; -- may contain only an instance of Bank_Account All_Accounts : Bank_Account.Class := F; -- may contain any value in the class of Bank_Account makes sense... -- ---------------------------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://perso.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-29 0:00 ` Jean-Pierre Rosen @ 1998-07-30 0:00 ` dennison 1998-07-30 0:00 ` Jean-Pierre Rosen 0 siblings, 1 reply; 138+ messages in thread From: dennison @ 1998-07-30 0:00 UTC (permalink / raw) In article <6pp9k8$77j$1@platane.wanadoo.fr>, "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote: > In a client-server model, I tend to favour the client against the server; in > this context, it means that I choose a name that maximizes readability of > the *variable declaration*, not of the *type declaration*. I guess that's where you start to loose me. My philosophy is that *both* sides need to be readable. After all, its just as likely (if not more) that the server will break as the client. But again, this is the best overall approach I have found so far. (Plus, it seems to be somewhat of a standard now). T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-30 0:00 ` dennison @ 1998-07-30 0:00 ` Jean-Pierre Rosen 0 siblings, 0 replies; 138+ messages in thread From: Jean-Pierre Rosen @ 1998-07-30 0:00 UTC (permalink / raw) dennison@telepath.com a �crit dans le message <6pq1mo$qm$1@nnrp1.dejanews.com>... >In article <6pp9k8$77j$1@platane.wanadoo.fr>, > "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote: >> In a client-server model, I tend to favour the client against the server; in >> this context, it means that I choose a name that maximizes readability of >> the *variable declaration*, not of the *type declaration*. > >I guess that's where you start to loose me. My philosophy is that *both* >sides need to be readable. After all, its just as likely (if not more) that >the server will break as the client. But again, this is the best overall >approach I have found so far. (Plus, it seems to be somewhat of a standard >now). > Of course, if you can have it both ways, it's better. I'm talking when a trade-off is necessary, and normally a package is used more often than it is maintained (hopefully :-). Thus my preference for the most common usage. ---------------------------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://perso.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-27 0:00 ` Jean-Pierre Rosen 1998-07-28 0:00 ` Matthew Heaney @ 1998-07-29 0:00 ` Robert I. Eachus 1998-07-30 0:00 ` Jean-Pierre Rosen 1998-07-30 0:00 ` Matthew Heaney 1 sibling, 2 replies; 138+ messages in thread From: Robert I. Eachus @ 1998-07-29 0:00 UTC (permalink / raw) In article <6pi71p$n90$1@platane.wanadoo.fr> "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > The trouble is that when you instantiate the generic, you can choose the > name of the new package, but not the names of what is declared inside, and > especially the type. I you want the type name to carry the useful > information, the type name should change with each instantiation! With my > notation, the package name carries the useful information, and therefore the > same convention can be used for packages obtained by generic instantiations > and for regular packages. Ah, but I always find myself doing the following: package Foobar is new Foo(....); type Something_Meaningful is new Foobar.Object_Type with null; -- and possibly function My_Op(Param: Something_Meaningful) return Integer; So both the use clause issue, and the meaningful name issue go away. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-29 0:00 ` Robert I. Eachus @ 1998-07-30 0:00 ` Jean-Pierre Rosen 1998-07-30 0:00 ` Robert I. Eachus 1998-07-30 0:00 ` Matthew Heaney 1 sibling, 1 reply; 138+ messages in thread From: Jean-Pierre Rosen @ 1998-07-30 0:00 UTC (permalink / raw) Robert I. Eachus a �crit dans le message ... >In article <6pi71p$n90$1@platane.wanadoo.fr> "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > > > The trouble is that when you instantiate the generic, you can choose the > > name of the new package, but not the names of what is declared inside, and > > especially the type. I you want the type name to carry the useful > > information, the type name should change with each instantiation! With my > > notation, the package name carries the useful information, and therefore the > > same convention can be used for packages obtained by generic instantiations > > and for regular packages. > > Ah, but I always find myself doing the following: > > package Foobar is new Foo(....); > type Something_Meaningful is new Foobar.Object_Type with null; > -- and possibly > function My_Op(Param: Something_Meaningful) return Integer; > > So both the use clause issue, and the meaningful name issue go away. I discussed the drawbacks of this approach in my paper (http://perso.wanadoo.fr/adalog/naming9x.zip, now includes the ppt version thanks Ted Dennison). Basically: forces you to use empty extension aggregate. If the package declares other stuff (like secondary types) you must reexport it manually. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-30 0:00 ` Jean-Pierre Rosen @ 1998-07-30 0:00 ` Robert I. Eachus 1998-07-31 0:00 ` Jean-Pierre Rosen 0 siblings, 1 reply; 138+ messages in thread From: Robert I. Eachus @ 1998-07-30 0:00 UTC (permalink / raw) I said: > Ah, but I always find myself doing the following:... > > So both the use clause issue, and the meaningful name issue go away. In article <6ppc3q$8ju$1@platane.wanadoo.fr> "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > I discussed the drawbacks of this approach in my paper > (http://perso.wanadoo.fr/adalog/naming9x.zip, now includes the ppt version > thanks Ted Dennison). > Basically: forces you to use empty extension aggregate. If the package > declares other stuff (like secondary types) you must reexport it manually. This is where we will have to leave it. I don't find adding "with null" offensive, and I usually do need to access secondary types, but the only sane way to do it is with a qualified names because there may be several types of that name (often the same one) in the derivation stack. A VERY simplified example: with Ada.Finalization; package People is type Person is tagged private; function Name(Who: in Person) return String; procedure Set_Name(Who: in out Person; Name: in String); function Address(Who: in Person) return String; function Set_Address(Who: in out Person; Address: in String); ... private package Add_Name is new Unbounded_String_Component( Ada.Finalization.Controlled); package Add_Address is new Unbounded_String_Component( Add_Name.Record_Type); type Person is new Add_Address.Record_Type with null; pragma Inline(Name, Set_Name, Address, Set_Address); end People; Now in the body I'll have to write things like: function Name(Who: in Person) return String is begin return Add_Name.Get(Who); end Name; I can't use a renaming as body, because Get takes a classwide parameter so I don't get driven crazy by adding conversions. Yes, you can use dispatching, but when you have twenty or so instantiations, it gets seriously confusing. why go to all the "trouble" required to build object classes like this? Because the operations required to display an object with dynamic updating and other niceties comes with the component packages. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-30 0:00 ` Robert I. Eachus @ 1998-07-31 0:00 ` Jean-Pierre Rosen 1998-07-31 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 138+ messages in thread From: Jean-Pierre Rosen @ 1998-07-31 0:00 UTC (permalink / raw) Very interesting, I think we are progressing... Robert I. Eachus a �crit dans le message ... > A VERY simplified example: > > with Ada.Finalization; > package People is > > type Person is tagged private; > > function Name(Who: in Person) return String; > procedure Set_Name(Who: in out Person; Name: in String); > function Address(Who: in Person) return String; > function Set_Address(Who: in out Person; Address: in String); > ... > > private > > package Add_Name is new Unbounded_String_Component( > Ada.Finalization.Controlled); > package Add_Address is new Unbounded_String_Component( > Add_Name.Record_Type); > type Person is new Add_Address.Record_Type with null; > > pragma Inline(Name, Set_Name, Address, Set_Address); > > end People; > > Now in the body I'll have to write things like: > > function Name(Who: in Person) return String is > begin return Add_Name.Get(Who); end Name; Your example is excellent, because you declare a *private* tagged type, and export its operations explicitely. But pragma Disclaimer (on); I do think, and often claim, that one of the big advantages of Ada over other OO languages is that you can use inheritance at *implementation* level without using it at specification level; or (like here) have hidden inheritances, that allow you to break the transitive dependence. I have therefore much sympathy for the way the example is written; however, we are discussing naming of classes in the general case here, in the context of "traditionnal" OO style. pragma Disclaimer (off); if you want to *visibly* add a facet, then it wouldn't work so easily (once again, look at the example in the paper). Why would you want to add visibly a facet ? Because this way, if you add new operations to a facet, they are immediately inherited by all users. If you instantiate privately, you'll have to add new "interface" routines to all packages. Granted, this is better from the point of view of encapsulation, but not from the point of view of flexibility. And the "pure OOP" approach is most effective in cases where flexibility is considered more important than encapsulation (but this is another debate). ---------------------------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://perso.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-31 0:00 ` Jean-Pierre Rosen @ 1998-07-31 0:00 ` Robert I. Eachus 1998-08-01 0:00 ` Jean-Pierre Rosen 0 siblings, 1 reply; 138+ messages in thread From: Robert I. Eachus @ 1998-07-31 0:00 UTC (permalink / raw) In article <6ps2ne$hko$1@platane.wanadoo.fr> "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > I do think, and often claim, that one of the big advantages of Ada over > other OO languages is that you can use inheritance at *implementation* level > without using it at specification level; or (like here) have hidden > inheritances, that allow you to break the transitive dependence. I have > therefore much sympathy for the way the example is written; however, we are > discussing naming of classes in the general case here, in the context of > "traditionnal" OO style... > Why would you want to add visibly a facet ? Because this way, if you add new > operations to a facet, they are immediately inherited by all users. If you > instantiate privately, you'll have to add new "interface" routines to all > packages. Granted, this is better from the point of view of encapsulation, > but not from the point of view of flexibility. And the "pure OOP" approach > is most effective in cases where flexibility is considered more important > than encapsulation (but this is another debate). That's why I said we have to leave it here. My style of developing in Ada 95 results in very few "open" types other than those where the descendent types are defined by generic instantiation. Therefore, I am the only person who sees inside the encapsulation. Jean-Pierre has stated several times that he uses a more open style, and explicitly designs expecting much more work to be done by the user of the type rather than the creator. Due to this difference in style, we will always reach different conclusions about how naming should be done. Maybe I can talk Jean-Pierre into my way of designing, but from experience, that is a very slow process. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-31 0:00 ` Robert I. Eachus @ 1998-08-01 0:00 ` Jean-Pierre Rosen 1998-08-04 0:00 ` Matthew Heaney 0 siblings, 1 reply; 138+ messages in thread From: Jean-Pierre Rosen @ 1998-08-01 0:00 UTC (permalink / raw) Robert I. Eachus a �crit: > > That's why I said we have to leave it here. My style of developing > in Ada 95 results in very few "open" types other than those where the > descendent types are defined by generic instantiation. Therefore, I > am the only person who sees inside the encapsulation. Jean-Pierre has > stated several times that he uses a more open style, and explicitly > designs expecting much more work to be done by the user of the type > rather than the creator. ??? I think I said in a previous message that the goal was to favour the *user* of a type against the *designer*... > Due to this difference in style, we will always reach different > conclusions about how naming should be done. Maybe I can talk > Jean-Pierre into my way of designing, but from experience, that is a > very slow process. Of course, we are discussing style here, so it's a matter of taste. As I mentionned before, I agree with you (and generally use) a "closed" style, and I try to keep inheritance as hidden as possible. However the purpose of this thread was to discuss a notation for those who want pure OO programming, and pure OO means a lot of visibility! Quoting Booch (from memory): "There is a very real tension between encapsulation and inheritence. To a large degree, inheritance exposes the secrets of the inherited class, sometimes including their inside view". -- ---------------------------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://perso.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-01 0:00 ` Jean-Pierre Rosen @ 1998-08-04 0:00 ` Matthew Heaney 1998-08-04 0:00 ` Jean-Pierre Rosen 0 siblings, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-08-04 0:00 UTC (permalink / raw) Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> writes: > Of course, we are discussing style here, so it's a matter of taste. > As I mentionned before, I agree with you (and generally use) a "closed" > style, and I try to keep inheritance as hidden as possible. However the > purpose of this thread was to discuss a notation for those who want pure > OO programming, and pure OO means a lot of visibility! Quoting Booch > (from memory): > "There is a very real tension between encapsulation and inheritence. To > a large degree, inheritance exposes the secrets of the inherited class, > sometimes including their inside view". A great quote that hints at the pitfalls of inheritance from a systems point of view. Visibility implies coupling, and coupling is bad. Very, very bad. An even better source is your own ACM paper "What orientation should Ada objects take?" It bravely challenges current dogma about inheritance as a mechanism for the composition of abstractions. (Thank you - I was cheering when I read it!) Everyone should also read "The Architecture of Complexity," by Herb Simon. It appears as a chapter in his book Sciences of the Artificial. Yes, the question might be "What naming convention do I use to effect pure OO programming in Ada 95?" But maybe we should be asking ourselves instead, "What is the simplest way to construct software systems using Ada 95?" If the system is modifiable and extensible, with minimal coupling among the parts, then should we really care whether a "pure OO" approach was used? Who even knows what "pure OO" means? ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-04 0:00 ` Matthew Heaney @ 1998-08-04 0:00 ` Jean-Pierre Rosen 1998-08-10 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 138+ messages in thread From: Jean-Pierre Rosen @ 1998-08-04 0:00 UTC (permalink / raw) Matthew Heaney a �crit dans le message ... >Yes, the question might be "What naming convention do I use to effect >pure OO programming in Ada 95?" But maybe we should be asking ourselves >instead, "What is the simplest way to construct software systems using >Ada 95?" Obviously a different, but interesting one. > >If the system is modifiable and extensible, with minimal coupling among >the parts, then should we really care whether a "pure OO" approach was >used? Who even knows what "pure OO" means? FWIW, here is the criteria that I use when I decide to use an inheritance based mechanism. -1) I need a family of types that are different enough for not considering them as "variants" of a single type (in which case a discriminated type would be prefered), but still have enough commonalities for applying common operations to all of them, and -2) I need to maintain heterogenous data structures of these types, and I need to apply the operations regardless of the specific type. A typical example (not very original) is widgets: a menu cannot be considered a variant of a window or a button, however there is a "paint" operation that applies to all, and I may have to keep a list of displayed widgets to which I want to apply Paint. Another example is for making persistent objects, where I maintain a list of caches for various object types, and where I want to flush all caches to the data base when the program terminates. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-04 0:00 ` Jean-Pierre Rosen @ 1998-08-10 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 138+ messages in thread From: Robert I. Eachus @ 1998-08-10 0:00 UTC (permalink / raw) In article <6q8utd$54o$1@platane.wanadoo.fr> "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > FWIW, here is the criteria that I use when I decide to use an inheritance > based mechanism. > -1) I need a family of types that are different enough for not considering > them as "variants" of a single type (in which case a discriminated type > would be prefered), but still have enough commonalities for applying common > operations to all of them, and > -2) I need to maintain heterogenous data structures of these types, and I > need to apply the operations regardless of the specific type. I was going to say I add a third group, but it isn't really that, it is more of a closure. I mostly to use inheritance and mixins as a decomposition technique. In Ada 95, I can keep details of structures like lists and queues separate from the contents. This is why I lean towards closed coding and naming that is really targetted towards the user in the package spec, and the author elsewhere. But that is the BIG difference between the way inheritance is used in other languages and the way I believe it should be used in Ada. Used right in Ada 95, inheritance reduces coupling and increases cohesion. I can have a list of target records where the code for list abstraction is totally decoupled from the declaration and operations of the target abstraction and vice-versa. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-29 0:00 ` Robert I. Eachus 1998-07-30 0:00 ` Jean-Pierre Rosen @ 1998-07-30 0:00 ` Matthew Heaney 1 sibling, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-07-30 0:00 UTC (permalink / raw) eachus@spectre.mitre.org (Robert I. Eachus) writes: > Ah, but I always find myself doing the following: > > package Foobar is new Foo(....); > type Something_Meaningful is new Foobar.Object_Type with null; > -- and possibly > function My_Op(Param: Something_Meaningful) return Integer; > > So both the use clause issue, and the meaningful name issue go away. Ahhh, the voice of reason in a chaotic world! Listen to the DRs guys! They know what they're doing! Thank you, thank you, thank you, thank you, thank you, ... Matt P.S. Did I say thank you, Bob? ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-26 0:00 ` Matthew Heaney 1998-07-26 0:00 ` nabbasi 1998-07-27 0:00 ` Jean-Pierre Rosen @ 1998-07-27 0:00 ` dennison 1998-07-27 0:00 ` Stephen Leake ` (2 more replies) 2 siblings, 3 replies; 138+ messages in thread From: dennison @ 1998-07-27 0:00 UTC (permalink / raw) In article <m367gl943o.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: > The "real" name of the type is the identifier used in the type > declaration, never the name of the enclosing package. No, its the package name PLUS the identifier used in the type declaration. Unless, of course you throw use clauses everywhere in your code. If you do that then it doesn't matter much what convention you use, I won't be able to read your code. We have preliminarliy standardized on the Package_Name.Instance notation here. I'm not sure I like it either, but I have yet to see a suggestion that is better when full name notation is used. The other suggestions I have seen here so far either redundantly name the type and the package, or encode the fact that it is a type in the type name or a package in the package name (duh). > You may think it looks nice, but I read this and think "Je crois qu'elle > est laide." Why not just > My_Account: Bank_Account; > Because that won't work. What you are really proposing is something like: My_Account: Bank_Account_Package.Bank_Account; ...which really reads worse and types much longer than: My_Account : Bank_Account.Instance; > You know, the way the language designers intended? Be careful. While this may be a nifty convention for ending discussions about the U.S. constitution, the Ada language designers aren't yet dead. In fact, they are still around and reading c.l.a. In my experience they have a rather annoying habit of piping in and disagreeing with me when I was sure they'd agree. :-) T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-27 0:00 ` dennison @ 1998-07-27 0:00 ` Stephen Leake 1998-07-27 0:00 ` dennison 1998-07-28 0:00 ` Matthew Heaney 1998-08-06 0:00 ` Robert A Duff 2 siblings, 1 reply; 138+ messages in thread From: Stephen Leake @ 1998-07-27 0:00 UTC (permalink / raw) dennison@telepath.com writes: > In article <m367gl943o.fsf@mheaney.ni.net>, > Matthew Heaney <matthew_heaney@acm.org> wrote: > > > The "real" name of the type is the identifier used in the type > > declaration, never the name of the enclosing package. > > No, its the package name PLUS the identifier used in the type declaration. > Unless, of course you throw use clauses everywhere in your code. If you do > that then it doesn't matter much what convention you use, I won't be able to > read your code. > > We have preliminarliy standardized on the Package_Name.Instance notation here. > I'm not sure I like it either, but I have yet to see a suggestion that is > better when full name notation is used. The other suggestions I have seen here > so far either redundantly name the type and the package, or encode the fact > that it is a type in the type name or a package in the package name (duh). How about Package_Name.Instance_Type? That makes clear the "type" vs "object" question. -- Stephe ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-27 0:00 ` Stephen Leake @ 1998-07-27 0:00 ` dennison 1998-07-27 0:00 ` Brian Rogoff 1998-07-28 0:00 ` Naming of Tagged Types and Associated Packages Norman H. Cohen 0 siblings, 2 replies; 138+ messages in thread From: dennison @ 1998-07-27 0:00 UTC (permalink / raw) In article <uogub2jq5.fsf@gsfc.nasa.gov>, Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote: > dennison@telepath.com writes: > > > We have preliminarliy standardized on the Package_Name.Instance notation here. > > I'm not sure I like it either, but I have yet to see a suggestion that is > > better when full name notation is used. The other suggestions I have seen here > > so far either redundantly name the type and the package, or encode the fact > > that it is a type in the type name or a package in the package name (duh). > > How about Package_Name.Instance_Type? That makes clear the "type" vs > "object" question. Again, you have encoded the fact that it is a type in the type's name. I don't need that information, and it leads to really stupid looking things like "Command_Type_Type". T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-27 0:00 ` dennison @ 1998-07-27 0:00 ` Brian Rogoff 1998-07-28 0:00 ` dennison 1998-07-28 0:00 ` Naming of Tagged Types and Associated Packages Norman H. Cohen 1 sibling, 1 reply; 138+ messages in thread From: Brian Rogoff @ 1998-07-27 0:00 UTC (permalink / raw) On Mon, 27 Jul 1998 dennison@telepath.com wrote: > Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote: > > dennison@telepath.com writes: > > > > > We have preliminarliy standardized on the Package_Name.Instance notation > here. > > > I'm not sure I like it either, but I have yet to see a suggestion that is > > > better when full name notation is used. The other suggestions I have seen > here > > > so far either redundantly name the type and the package, or encode the fact > > > that it is a type in the type name or a package in the package name (duh). > > > > How about Package_Name.Instance_Type? That makes clear the "type" vs > > "object" question. > > Again, you have encoded the fact that it is a type in the type's name. I don't > need that information, and it leads to really stupid looking things like > "Command_Type_Type". The first part of your assertion, that you don't *need* this information, is certainly correct. If you can't stand redundancy, you should dump Ada, and embrace either C++, which enables you to do away with many explicit generic instantiations, or a language with type-inference, like ML, Haskell, or Mercury, which lets you do away with almost all explicit typing and still gives you static type checking. :-) :-) The second part of your assertion, that it leads to stupid things like Command_Type_Type, is completely false. I use the _Type convention, and and a similar convention in C, I've never had this problem arise. If you don't like that convention, fine, but don't just make up problems which don't really happen . If you only have one main type per package, why not give it a single letter name like T or I (for Instance, yuk!)? -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-27 0:00 ` Brian Rogoff @ 1998-07-28 0:00 ` dennison 1998-07-28 0:00 ` Brian Rogoff 0 siblings, 1 reply; 138+ messages in thread From: dennison @ 1998-07-28 0:00 UTC (permalink / raw) In article <Pine.BSF.3.96.980727153418.13706B-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > The second part of your assertion, that it leads to stupid things like > Command_Type_Type, is completely false. I use the _Type convention, and > and a similar convention in C, I've never had this problem arise. If you > don't like that convention, fine, but don't just make up problems which > don't really happen . Hmmm. I've seen it happen all over the place, in my code and others. Maybe it hasn't happened to *you*, but that doesn't mean it doesn't happen. Heck, if that logic works, I assert that death does not exist. After all, it hasn't ever happened to me. Ha Ha! Now I'll live forever. Suffer, mortal fools! :-) If you *like* the "Hungarian notation"-like conventions that are common in C work, that's fine. But you aren't going to be able to convince me its a good thing for Ada any more than I can convince you its not. In the meantime, we horribly bore everyone else. It's best to just not go there. > If you only have one main type per package, why not give it a single > letter name like T or I (for Instance, yuk!)? Actually, that's a very valid point (I may be misreading you here, but heck, I'm going with it). "Instance" is so undescriptive, it might as well be "I". That's part of the reason I'm not entirely satisfied with the Package_Name.Instance convention. T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` dennison @ 1998-07-28 0:00 ` Brian Rogoff 1998-07-28 0:00 ` Brian Rogoff 1998-07-28 0:00 ` dennison 0 siblings, 2 replies; 138+ messages in thread From: Brian Rogoff @ 1998-07-28 0:00 UTC (permalink / raw) On Tue, 28 Jul 1998 dennison@telepath.com wrote: > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > The second part of your assertion, that it leads to stupid things like > > Command_Type_Type, is completely false. I use the _Type convention, and > > and a similar convention in C, I've never had this problem arise. If you > > don't like that convention, fine, but don't just make up problems which > > don't really happen . > > Hmmm. I've seen it happen all over the place, in my code and others. Maybe it > hasn't happened to *you*, but that doesn't mean it doesn't happen. Heck, if > that logic works, I assert that death does not exist. After all, it hasn't > ever happened to me. Ha Ha! Now I'll live forever. Suffer, mortal fools! :-) Good one! However, my point wasn't that you couldn't do it, just that you'd have to be deliberately silly to do so (come on Ted, you really couldn't think of a better name than Command_Type_Type?). It would be like me using single letter names for everything, and then using the ensuing confusion to argue that names without the "_Type" are hopelessly confusing. Anyways, don't make up silly arguments against my preferred naming convention, and I promise not to comment on it again, OK? ;-) > > If you only have one main type per package, why not give it a single > > letter name like T or I (for Instance, yuk!)? > > Actually, that's a very valid point (I may be misreading you here, but heck, > I'm going with it). "Instance" is so undescriptive, it might as well be "I". You read me perfectly, though I'd prefer "T" to "I" as the name of the main type, for the reasons being discussed elsewhere. Also, this convention is widely used by our cousins in the Modula-3 community, and I'm told it is used in the Ada community too, ar least for explanation. It also makes sense if you eschew use clauses, and name your packages with the "class" name, in a module = type style of OOP. My issue with this is that I often coencapsulate types, and sometimes there is no main type in a package, though I suppose thats easy enough to fix by using T,U,V,W, ... or T1, T2, T3, ... -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` Brian Rogoff @ 1998-07-28 0:00 ` Brian Rogoff 1998-07-29 0:00 ` Matthew Heaney 1998-07-28 0:00 ` dennison 1 sibling, 1 reply; 138+ messages in thread From: Brian Rogoff @ 1998-07-28 0:00 UTC (permalink / raw) On Tue, 28 Jul 1998, Brian Rogoff wrote: > My issue with this is that I often coencapsulate types, and sometimes > there is no main type in a package, though I suppose thats easy enough to > fix by using T,U,V,W, ... or T1, T2, T3, ... Oops, I forgot to put a string of ":-)" here! -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` Brian Rogoff @ 1998-07-29 0:00 ` Matthew Heaney 1998-07-29 0:00 ` Brian Rogoff 0 siblings, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-07-29 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> writes: > On Tue, 28 Jul 1998, Brian Rogoff wrote: > > My issue with this is that I often coencapsulate types, and sometimes > > there is no main type in a package, though I suppose thats easy enough to > > fix by using T,U,V,W, ... or T1, T2, T3, ... > > Oops, I forgot to put a string of ":-)" here! But you bring up a good point. Frequently, there are types that are cohesive enough that they really belong together in the same package. An example is a data structure (say a stack or queue) and its associated active iterator, connected by a factory method. The problem is, if you name the stack type Instance, then what do you name the iterator type? ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-29 0:00 ` Matthew Heaney @ 1998-07-29 0:00 ` Brian Rogoff 0 siblings, 0 replies; 138+ messages in thread From: Brian Rogoff @ 1998-07-29 0:00 UTC (permalink / raw) On Wed, 29 Jul 1998, Matthew Heaney wrote: > Brian Rogoff <bpr@shell5.ba.best.com> writes: > > On Tue, 28 Jul 1998, Brian Rogoff wrote: > > > My issue with this is that I often coencapsulate types, and sometimes > > > there is no main type in a package, though I suppose thats easy enough to > > > fix by using T,U,V,W, ... or T1, T2, T3, ... > > > > Oops, I forgot to put a string of ":-)" here! > > But you bring up a good point. Frequently, there are types that are > cohesive enough that they really belong together in the same package. > An example is a data structure (say a stack or queue) and its associated > active iterator, connected by a factory method. Thats one good example, and thats why the joking suggestion about numbering the type names should have gotten a smiley. Another similar example is the "index" type of a random access collection. I find that violations of the one-main-type-per-package rule occur very frequently. What I have done in my own generic collection libraries, whose source you can peruse at http://www.best.com/~bpr/agl.html, is stick the iterators in child packages of the collection, so I suppose I could make the T convention work, if I wanted to. -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` Brian Rogoff 1998-07-28 0:00 ` Brian Rogoff @ 1998-07-28 0:00 ` dennison 1998-07-29 0:00 ` Matthew Heaney 1 sibling, 1 reply; 138+ messages in thread From: dennison @ 1998-07-28 0:00 UTC (permalink / raw) In article <Pine.BSF.3.96.980728084100.28778A-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > Good one! However, my point wasn't that you couldn't do it, just that > you'd have to be deliberately silly to do so (come on Ted, you really > couldn't think of a better name than Command_Type_Type?). It would Its not something that is typically done just to be silly. In fact, the issue comes up among other places on nearly every record that has an enumerated variant. A very typical example: I have a command that gets passed to a routine for processing. The standard says it should be named Command_Type. It is implemented with several "data" fields and an enumeration field specifing what the actual command is (what "type" of command it is). The natural name for that is Command_Type. Under the naming convetion, it becomes Command_Type_Type. Again, this isn't something that's deliberately done by me to be silly (lord knows I do plenty of those). Its something that I have seen come up often in *other*people's* code. I've worked on a couple of programs where the lead engineer got the coding standards written so that putting "_type" on the end of every type was specifically *forbidden*. Usually derisive verbal abuse from fellow engineers is enough to do the job, though. :-) T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` dennison @ 1998-07-29 0:00 ` Matthew Heaney 1998-07-29 0:00 ` Chris Brand 0 siblings, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-07-29 0:00 UTC (permalink / raw) dennison@telepath.com writes: > A very typical example: I have a command that gets passed to a routine for > processing. The standard says it should be named Command_Type. It is > implemented with several "data" fields and an enumeration field specifing > what the actual command is (what "type" of command it is). The natural name > for that is Command_Type. Under the naming convetion, it becomes > Command_Type_Type. Although I don't use the _Type convention (it should be used only for "static polymorphism," as it is in the RM), you can get around the problem you describe by naming the type "Command_Kind." This avoids any potential ambiguity about whether it's a command or just a kind of command. > I've worked on a couple of programs where the lead engineer got the coding > standards written so that putting "_type" on the end of every type was > specifically *forbidden*. Give that guy a medal for doing the smart thing. The types in the RM aren't named using _Type, so why do it that way in your code? ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-29 0:00 ` Matthew Heaney @ 1998-07-29 0:00 ` Chris Brand 1998-07-30 0:00 ` Matthew Heaney 0 siblings, 1 reply; 138+ messages in thread From: Chris Brand @ 1998-07-29 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > The types in the RM > aren't named using _Type, so why do it that way in your code? Except, of course, Ada.Text_IO.File_Type. -- Chris Stating my own opinions, not those of my company. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-29 0:00 ` Chris Brand @ 1998-07-30 0:00 ` Matthew Heaney 1998-07-30 0:00 ` dennison ` (2 more replies) 0 siblings, 3 replies; 138+ messages in thread From: Matthew Heaney @ 1998-07-30 0:00 UTC (permalink / raw) Chris Brand <cbrand@west.raytheon.com> writes: > Matthew Heaney wrote: > > > > The types in the RM > > aren't named using _Type, so why do it that way in your code? > > Except, of course, Ada.Text_IO.File_Type. Good point. The reason (I think - the DRs will correct me if I'm wrong) for the the _Type convention for files has to do with "static polymorphism." "Static polymorphism" you say? Hmmm? How can polymorphism - usually associated with dynamic behavior - be static? Suppose we named type Direct_IO.File_Type "Direct_File", and suppose we named Sequential_IO.File_Type "Sequential_File". I've argued for this kind of thing in the past, but here's why it's a bad idea. I need a sequential file type, so I instantiate generic package Sequential_IO on my type, and then declare a bunch of instances: package T_IO is new Sequential_IO (T); use T_IO; procedure Op1 is File : Sequential_File; begin ... procedure Op2 is File : Sequential_File; begin ... procedure Op3 is File : Sequential_File; begin ... You get the idea. Everywhere where I declare a file instance, the type is named Sequential_File. Now, suppose that as a build the software, or a requirement changes (not unlikely), I realize that I need direct file access, not just sequential access. The means I have to do a new instantiation, and everywhere where there's a Sequential_File, there's now needs to be a Direct_File. If I'm lucky, the change might be in a single package body, and I can use a search & replace to do the change. But I might not be so lucky, and I might accidently change other file instances that shouldn't be changed. If I'm really unlucky, then the name might be spread across packages, and I have to change a bunch of code that causes a massive recompile on the entire system. You get the idea. The best approach is the not have to do any editing at all, and only change which file package is being instantiated. So let's use a neutral name like "File_Type", so that that all I have to do is make a single change - to change the instantiation from Sequential_IO to Direct_IO. All the file objects have the same type name. All the operations have the same signiture too, so no code needs changed. If I need to know the characteristics of a file instance (to determine whether it's sequential or direct), then I don't need to be reminded of this every time I declare an object. All I need to do is state that information once, at the point of instantiation of the generic file package. That is why the interfaces for Sequential_IO and Direct_IO are identical. It's sorta like deriving each file type from an abstract root type. Instead of refering to a class-wide type called Root_File'Class and doing dynamic dispatching on primitive operations, you refer to a "root type" called File_Type, and invoke primitive operations statically. I've written a data structures library that does this kind of thing. No, I did not create a type hierarchy rooted at Root_Stack, with different stacks deriving from Root_Stack. No (public) tagged types or inheritance were needed thank you very much. I simply have different kinds of stacks that are NOT part of a type hierarchy, but do have identical interfaces. Just like Sequential_IO and Direct_IO. Because I want a client to be able to easily change the code if he changes his mind about what kind of stack he needs (say, to go from a bounded stack to a dynamic stack with a statically allocated heap), I just named all the stack types Stack_Type. (Brian Rogoff must be smiling right now...) Just like File_Type. This does not mean, however, that you should name every type using the _Type convention. This is a big mistake, because then the convention would loose its value as an indicator of static polymorphism. For example, the active iterator for the Stack_Type is called Stack_Iterator. It's not just any Iterator_Type, it's an iterator for stacks, so call it that. This is exactly like file mode, which is not called Mode_Type. It's call File_Mode. Because it's not just any mode type, it's a file mode, so call they called it that. All the conventions you need are right there in the RM. You don't need to do anything different from the RM, because the DRs already figured it out. So take their advice about how to program in Ada, and do as the RM does. So I'll say it again: naming types "Instance" is a bad idea, for no other reason than that is not a convention that appears in the RM. (There are other reasons it's not a good idea, but those have been debated in other posts.) ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-30 0:00 ` Matthew Heaney @ 1998-07-30 0:00 ` dennison 1998-07-30 0:00 ` Matthew Heaney 1998-08-01 0:00 ` Simon Wright 1998-08-05 0:00 ` Static Polymorphism (Was Re: Naming of Tagged Types...) Brian Rogoff 2 siblings, 1 reply; 138+ messages in thread From: dennison @ 1998-07-30 0:00 UTC (permalink / raw) In article <m3vhogw00r.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: > So let's use a neutral name like "File_Type", so that that all I have to > do is make a single change - to change the instantiation from > Sequential_IO to Direct_IO. All the file objects have the same type > name. All the operations have the same signiture too, so no code needs > changed. I still whould have gone with "File" instead of "File_Type". :-) T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-30 0:00 ` dennison @ 1998-07-30 0:00 ` Matthew Heaney 1998-07-30 0:00 ` dennison 0 siblings, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-07-30 0:00 UTC (permalink / raw) dennison@telepath.com writes: > I still whould have gone with "File" instead of "File_Type". > :-) I'm not sure why there's a smiley there, but in general, types should be named using a two-part phrase. That way you can name the object using a shortened version of the type name, as in Kind : Command_Kind; File : File_Type; Pool : Storage_Pool; Speed : Speed_In_MPH; etc. If you name the type File, then you have to name the object The_File, but the definate article just adds noise (not unlike the over-use of _Type...) that your reader is going to mentally parse out anyway. This was the style used by Booch way back when, but I find it a bit old-fashioned nowadays. As I mentioned in another post, a similar idiom applies to a type hierarchy. The root type of the hierarchy should be named with a two-part phrase, for example Root_Stack or Bank_Account. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-30 0:00 ` Matthew Heaney @ 1998-07-30 0:00 ` dennison 0 siblings, 0 replies; 138+ messages in thread From: dennison @ 1998-07-30 0:00 UTC (permalink / raw) In article <m3pvenww5v.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: > dennison@telepath.com writes: > > > I still whould have gone with "File" instead of "File_Type". > > :-) > > I'm not sure why there's a smiley there, but in general, types should be > named using a two-part phrase. That way you can name the object using a > shortened version of the type name, as in The smiley was there because this is clearly a matter of taste. The rule I live by is that objects (including types) should be named as specific to the role they serve as is reasonable. Couple that with full dot notation and name clashes really are rather rare. For instance your declaration for file becomes: File : Configuration_IO.File; or better yet, something like: Configuration_File : Configuration_IO.File; ...but that's me. T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-30 0:00 ` Matthew Heaney 1998-07-30 0:00 ` dennison @ 1998-08-01 0:00 ` Simon Wright 1998-08-02 0:00 ` Matthew Heaney 1998-08-05 0:00 ` Static Polymorphism (Was Re: Naming of Tagged Types...) Brian Rogoff 2 siblings, 1 reply; 138+ messages in thread From: Simon Wright @ 1998-08-01 0:00 UTC (permalink / raw) Matthew Heaney <matthew_heaney@acm.org> writes: > You get the idea. Everywhere where I declare a file instance, the type > is named Sequential_File. > > Now, suppose that as a build the software, or a requirement changes (not > unlikely), I realize that I need direct file access, not just sequential > access. The means I have to do a new instantiation, and everywhere > where there's a Sequential_File, there's now needs to be a Direct_File. So why not call them just File? (OK, you can't "use" with such gay abandon, good thing too :-) ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-01 0:00 ` Simon Wright @ 1998-08-02 0:00 ` Matthew Heaney 1998-08-03 0:00 ` dennison ` (2 more replies) 0 siblings, 3 replies; 138+ messages in thread From: Matthew Heaney @ 1998-08-02 0:00 UTC (permalink / raw) Simon Wright <simon@pogner.demon.co.uk> writes: > Matthew Heaney <matthew_heaney@acm.org> writes: > > > You get the idea. Everywhere where I declare a file instance, the type > > is named Sequential_File. > > > > Now, suppose that as a build the software, or a requirement changes (not > > unlikely), I realize that I need direct file access, not just sequential > > access. The means I have to do a new instantiation, and everywhere > > where there's a Sequential_File, there's now needs to be a Direct_File. > > So why not call them just File? (OK, you can't "use" with such gay > abandon, good thing too :-) Because that's what I want to call the instance of the type: File. In an Ada declaration, the object and the type can't have the same name. If the object is called File, then the type has to be called something else. (Note that Eiffel doesn't have this "problem," because the object and its type are in different namespaces.) That's why I recommend using a two-word phrase to name types. General types like Integer don't have to follow this convention, because there's no danger of an object ever being named Integer. I gave reasons in the previous post why you should use the _Type convention only for certain situations (as an indicator of "static polymorphism"). To use that convention everywhere only adds noise that your reader is going to have to mentally remove. Someone responded by arguing that you could do this: declare File : Configuration_IO.File; begin but I don't care for this because it has the same problem as Jean-Pierre's Package_Name.Instance convention: it tries to elevate the package name to the same status as a type name. A package name is not a type name, because a package is not a type. A package is a namespace, and it exists only (more or less) to prevent name clashes among identically named types. Use expanded name notation ONLY when you have identically named types in the same scope. Please do not use expanded name notation to prevent a name clash between object name and the type name. You might argue that you could name the object, instead of the type, using the long form: declare Configuration_File : File; begin but this too is a mistake. You only need to state the properties of the object _once_, during its declaration. When you use the long form for the object, then you are adding noise everywhere the object is used, which the reader is just going to mentally strip out anyway. The idea is that you should say what you want to say by stating as little information as possible. This is the essence of abstraction. If the reader wants more information, then give him an easy path to find it. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-02 0:00 ` Matthew Heaney @ 1998-08-03 0:00 ` dennison 1998-08-03 0:00 ` Matthew Heaney 1998-08-04 0:00 ` Jean-Pierre Rosen 1998-08-05 0:00 ` Don Harrison 2 siblings, 1 reply; 138+ messages in thread From: dennison @ 1998-08-03 0:00 UTC (permalink / raw) In article <m37m0suor4.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: > Simon Wright <simon@pogner.demon.co.uk> writes: > > > So why not call them just File? (OK, you can't "use" with such gay > > abandon, good thing too :-) > > Someone responded by arguing that you could do this: > > declare > File : Configuration_IO.File; > begin > > but I don't care for this because it has the same problem as > Jean-Pierre's Package_Name.Instance convention: it tries to elevate the > package name to the same status as a type name. No, its not the type name. But it is used as *part* of the type name. Think of it as a family name. Just like "Romeo Montague" means "Romeo of the family Montague", Configuration_IO.File means "File of the package Configuration_IO". T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-03 0:00 ` dennison @ 1998-08-03 0:00 ` Matthew Heaney 1998-08-04 0:00 ` dennison 0 siblings, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-08-03 0:00 UTC (permalink / raw) dennison@telepath.com writes: > No, its not the type name. But it is used as *part* of the type > name. Think of it as a family name. Just like "Romeo Montague" means > "Romeo of the family Montague", Configuration_IO.File means "File of > the package Configuration_IO". "The" type name or just "part" of the type name, I don't see any difference. You're giving me a personal model is what a type name is. Fair enough, that's your model. But I prefer to stick to the model in the RM. And in the RM, file types are all named File_Type. There is a reason. In a declaration, the object name and type name share a namespace. I think the intent was that object and type have different names. And by type "name" I mean without using expanded name notation. I don't think the intent was to use expanded name notation to resolve the namespace clash in an object declaration. Expanded name notation should be used only to qualify identically named types in the same scope. If the designers of the language had wanted you to name the object and type the same, then they would have specified the language so that object and type have different namespaces _automatically_. (This is indeed the choice Meyer made with Eiffel.) So you could do this: File : File; legally. But the Ada designers didn't do that. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-03 0:00 ` Matthew Heaney @ 1998-08-04 0:00 ` dennison 0 siblings, 0 replies; 138+ messages in thread From: dennison @ 1998-08-04 0:00 UTC (permalink / raw) In article <m3pveiju8i.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: > You're giving me a personal model is what a type name is. Fair enough, > that's your model. But I prefer to stick to the model in the RM. And > in the RM, file types are all named File_Type. There is a reason. Yeah. The reason was: that was the first application *ever* written in Ada, and they didn't know any better. :-) T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-02 0:00 ` Matthew Heaney 1998-08-03 0:00 ` dennison @ 1998-08-04 0:00 ` Jean-Pierre Rosen 1998-08-04 0:00 ` Brian Rogoff 1998-08-05 0:00 ` Don Harrison 2 siblings, 1 reply; 138+ messages in thread From: Jean-Pierre Rosen @ 1998-08-04 0:00 UTC (permalink / raw) Matthew Heaney a �crit dans le message ... >A package name is not a type name, because a package is not a type. A >package is a namespace, and it exists only (more or less) to prevent >name clashes among identically named types. > This is absolutely true from the point of view of the *language definition*. However, you *use* it to form higher level abstractions. It then becomes that higher level abstraction. For example, a paint is just a chemical product with peculiar optical properties, but when used in a certain way, it becomes the Joconde... A package used in a certain way makes up a class (in classical OO mode). When used otherwise, it may become something else, and I 100% agree that different conventions might then be preferable. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-04 0:00 ` Jean-Pierre Rosen @ 1998-08-04 0:00 ` Brian Rogoff 0 siblings, 0 replies; 138+ messages in thread From: Brian Rogoff @ 1998-08-04 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 1213 bytes --] On Tue, 4 Aug 1998, Jean-Pierre Rosen wrote: > Matthew Heaney a écrit dans le message ... > >A package name is not a type name, because a package is not a type. A > >package is a namespace, and it exists only (more or less) to prevent > >name clashes among identically named types. > > > This is absolutely true from the point of view of the *language > definition*. However, you *use* it to form higher level abstractions. > It then becomes that higher level abstraction. > For example, a paint is just a chemical product with peculiar optical > properties, but when used in a certain way, it becomes the Joconde... > > A package used in a certain way makes up a class (in classical OO mode). > When used otherwise, it may become something else, and I 100% agree that > different conventions might then be preferable. Just a small point, which I'm sure Jean-Pierre understands, a class, in classical OO mode, is neither a package, nor a type, but combines elements of both. I think its just as correct, maybe more :-), to say that a tagged type used a certain way makes up a class. By "classical OO" here I mean Eiffel style OO in which every module is a type. -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-02 0:00 ` Matthew Heaney 1998-08-03 0:00 ` dennison 1998-08-04 0:00 ` Jean-Pierre Rosen @ 1998-08-05 0:00 ` Don Harrison 1998-08-05 0:00 ` Brian Rogoff 1998-08-05 0:00 ` Matthew Heaney 2 siblings, 2 replies; 138+ messages in thread From: Don Harrison @ 1998-08-05 0:00 UTC (permalink / raw) Matt Heaney wrote: :In an Ada declaration, the object and the type can't have the same name. :If the object is called File, then the type has to be called something :else. (Note that Eiffel doesn't have this "problem," because the object :and its type are in different namespaces.) I think it's not so much namespaces but the fact that the syntax allows you (and the compiler) to easily differentiate variables (entities in Eiffel parlance) from types. Some examples.. 1) Variable declarations: variable : TYPE The identifier to the left of the colon is recognised as a variable and the one on the right as a type. 2) Variable instantiations: !TYPE!variable The identifier framed by exclamation marks is recognised as a type and the one following as a variable. 3) Selective export: feature {TYPE} Any identifier enclosed in curly brackets is a type. 4) Constrained generic parameters: class GENERIC_TYPE [G -> TYPE] All constrained generic parameters are types. etc. Don. Don Harrison donh at syd.csa.com.au ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-05 0:00 ` Don Harrison @ 1998-08-05 0:00 ` Brian Rogoff 1998-08-07 0:00 ` doylep 1998-08-07 0:00 ` Don Harrison 1998-08-05 0:00 ` Matthew Heaney 1 sibling, 2 replies; 138+ messages in thread From: Brian Rogoff @ 1998-08-05 0:00 UTC (permalink / raw) On Wed, 5 Aug 1998, Don Harrison wrote: > Matt Heaney wrote: > > :In an Ada declaration, the object and the type can't have the same name. > :If the object is called File, then the type has to be called something > :else. (Note that Eiffel doesn't have this "problem," because the object > :and its type are in different namespaces.) > > I think it's not so much namespaces but the fact that the syntax allows > you (and the compiler) to easily differentiate variables (entities in > Eiffel parlance) from types. Well, I hate to agree with my mortal enemy Matthew :-), but for this to be correct it would have to be the case that Ada syntax doesn't allow you to differentiate types and variables in the analogous Ada constructs. At least for your examples, this is obviously not true. So Matthew's point stands, it is the separate namespaces, not the syntax, that allows you to use the same names for types and variables. I find that very ugly, but I'm sure if I used Eiffel long enough my abhorence would diminish. -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-05 0:00 ` Brian Rogoff @ 1998-08-07 0:00 ` doylep 1998-08-07 0:00 ` Brian Rogoff 1998-08-08 0:00 ` Matthew Heaney 1998-08-07 0:00 ` Don Harrison 1 sibling, 2 replies; 138+ messages in thread From: doylep @ 1998-08-07 0:00 UTC (permalink / raw) In article <Pine.BSF.3.96.980805092758.8504A-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > [...] that allows you to > use the same names for types and variables. I find that very ugly, but I'm > sure if I used Eiffel long enough my abhorence would diminish. I think you would, for two reasons: 1. Nothing's stopping you from making yourself use different names for everything. 2. It allows you to avoid contrivances by permitting things like this: class CAR feature steering_wheel : STEERING_WHEEL end What else are you going to call the steering wheel? A direction_control_device? I think any other name would be contrived. -PD -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-07 0:00 ` doylep @ 1998-08-07 0:00 ` Brian Rogoff 1998-08-08 0:00 ` Matthew Heaney ` (2 more replies) 1998-08-08 0:00 ` Matthew Heaney 1 sibling, 3 replies; 138+ messages in thread From: Brian Rogoff @ 1998-08-07 0:00 UTC (permalink / raw) Thanks for bringing this back to c.l.a, Patrick. I was loathe to respond to this in c.l.e., as I remember several language wars starting from c.l.ada/eiffel crossposting, and I just don't care for them. On Fri, 7 Aug 1998 doylep@ecf.toronto.edu wrote: > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > [...] that allows you to > > use the same names for types and variables. I find that very ugly, but I'm > > sure if I used Eiffel long enough my abhorence would diminish. should be "abhorrence", sorry. > > I think you would, for two reasons: My main reason was that I'll get used to anything given time, including C++, Perl, pro-wrestling, Taco Bell, ... > 1. Nothing's stopping you from making yourself use different names for > everything. True, but I can't stop other programmers from doing it, and I suspect from these postings that this may be a common practice in Eiffel. Overall, I think this is a fairly minor nit to pick, but then we wouldn't be programmers if we didn't like to argue over minor nits, would we? > 2. It allows you to avoid contrivances by permitting things like this: > > class CAR > > feature > steering_wheel : STEERING_WHEEL > > end > > What else are you going to call the steering wheel? A > direction_control_device? I think any other name would be contrived. Call the steering wheel Steering_Wheel, and call the type something like Steering_Wheel_Type, or Steering_Wheel_T. Personally, I like type names and variable names to be lexically distinguished, so the EuLisp/Dylan convention, which would be to name it something like <SteeringWheel>, would be my choice if I could do it all myself, but I don't think the _Type convention is bad at all, and its used widely in my Ada reference of choice (Ada as a Second Language). If you want to talk about having to create contrived names, be careful, Eiffel doesn't have overloading, which is far worse IMO. Apparently the Sather designers agreed, when they decided to "fix" Eiffel, they added overloading. Other languages, like OCaml, do away with most of the need to name types altogether, so the antiredundantists should consider such languages before disparaging the Ada way in deference to Eiffel way. pragma Rant(On); The truth is I don't think I'll use Eiffel again, because I don't think its a very good language design. I think OO is overrated, and languages that try to enforce OO as the *only* programming tool are not for me. I like Eiffel's assertion mechanisms (though I'm not sure they belong in the language or would be better left as a tool) but I think its type system is hopelessly broken, it *requires* whole-program analysis due to covariance; bye-bye separate compilation! OTOH, despite the fact that Ada has numerous annoying flaws and misfeatures, I find the overall language design quite sound. It supports the OO style well, but doesn't enforce it, and allows you not to use it at all if it isn't what you want. Obviously, people are free to have different opinions, and I wouldn't want to start another Eiffel/Ada flamefest, so I generally avoid posting my opinion on the Eiffel ng. pragma Rant(Off); -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-07 0:00 ` Brian Rogoff @ 1998-08-08 0:00 ` Matthew Heaney 1998-08-10 0:00 ` doylep 1998-08-12 0:00 ` Don Harrison 2 siblings, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-08-08 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> writes: > The truth is I don't think I'll use Eiffel again, because I don't think > its a very good language design. I think OO is overrated, and languages > that try to enforce OO as the *only* programming tool are not for me. You sometimes hear Ada refered to as "a 70's language." I sometimes think of Eiffel as "an 80's language," since it forces one to program using a "pure" object-oriented paradigm. What's so great about "pure" object-oriented programming, anyway? Not having done any programming in Eiffel, I'm not going to comment on the design of that language, but I agree that object-oriented programming is only one tool among many that a programmer should have at his disposal. The OO hype left over from the 80's hasn't quite subsided, but the tide is turning. People are finally beginning to realize that using (public) inheritence to compose abstractions creates too many dependencies, which can stymie the growth of a large system in development. Indeed, the debates about the "proper" taxonomy for an inheritence tree are redolent of the debates we had in the 70's about what the "proper" decomposition of functions should be. This is ironic, since the object-oriented paradigm was intended to silence those debates! Creating deep (public) inheritence hierarchies, though typical in "pure OO" languages, is definately not a technique that should be used in Ada95 or C++, where objects have value semantics. Another thread on this list has alluded to the better way, using "closed" abstractions that use inheritence as a private, implementation mechanism. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-07 0:00 ` Brian Rogoff 1998-08-08 0:00 ` Matthew Heaney @ 1998-08-10 0:00 ` doylep 1998-08-10 0:00 ` Brian Rogoff ` (2 more replies) 1998-08-12 0:00 ` Don Harrison 2 siblings, 3 replies; 138+ messages in thread From: doylep @ 1998-08-10 0:00 UTC (permalink / raw) In article <Pine.BSF.3.96.980807163858.838A-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > Thanks for bringing this back to c.l.a, Patrick. I was loathe to respond > to this in c.l.e., as I remember several language wars starting from > c.l.ada/eiffel crossposting, and I just don't care for them. Yes, that's the same reason I am usually too afraid to venture into c.l.a. :-) > On Fri, 7 Aug 1998 doylep@ecf.toronto.edu wrote: > > > 1. Nothing's stopping you from making yourself use different names for > > everything. > > True, but I can't stop other programmers from doing it Good point. > > 2. It allows you to avoid contrivances by permitting things like this: > > > > class CAR > > > > feature > > steering_wheel : STEERING_WHEEL > > > > end > > > > What else are you going to call the steering wheel? A > > direction_control_device? I think any other name would be contrived. > > Call the steering wheel Steering_Wheel, and call the type something like > Steering_Wheel_Type, or Steering_Wheel_T. Personally, I like type names > and variable names to be lexically distinguished, so the EuLisp/Dylan > convention, which would be to name it something like <SteeringWheel>, > would be my choice if I could do it all myself, but I don't think the > _Type convention is bad at all, and its used widely in my Ada reference > of choice (Ada as a Second Language). The Eiffel convention is to use uppercase for class names and lowercase for feature names. Does this fit the bill? Some compilers won't even accept source code that does not follow this convention, so other programmers not conforming is not an issue. > If you want to talk about having to create contrived names, be careful, > Eiffel doesn't have overloading, which is far worse IMO. Apparently the > Sather designers agreed, when they decided to "fix" Eiffel, they added > overloading. Other languages, like OCaml, do away with most of the need > to name types altogether, so the antiredundantists should consider such > languages before disparaging the Ada way in deference to Eiffel way. Perhaps, but preventing redundancy is still a good thing, so the fact that a language is redundant in one sense doesn't change the fact that eliminating redundancy in another sense is a Good Thing. > pragma Rant(On); > > The truth is I don't think I'll use Eiffel again, because I don't think > its a very good language design. I think OO is overrated, and languages > that try to enforce OO as the *only* programming tool are not for me. I > like Eiffel's assertion mechanisms (though I'm not sure they belong in the > language or would be better left as a tool) but I think its type system is > hopelessly broken, it *requires* whole-program analysis due to covariance; > bye-bye separate compilation! Fair enough. I don't like covariance either. But as for whole-program analysis... First, this is not necessary if you're satisfied with some type checking being done at runtime. So the accurate assessment would be that whole-program analysis is required for static type safety, rather than to make Eiffel usable at all. Second, SmallEiffel is a compiler which has dived whole-heartedly into a system-wide approach, and as such is able to make *massive* optimisations which produce excellent executables. Since the compiler is compiled by itself, it makes use of these optimisations to provide system-wide compilation which is of comparable speed to module-wise compilation systems. In fact, because SmallEiffel compiles to C, it is possible to compare the system-wide approach to the module-wise approach directly, and the Eiffel-to-C phase of compilation is invariably faster than the C-to-native phase, often by an order of magnitude, despite the fact that the C-to-native phase only compiles the portions that have changed. It is dangerous to draw too many conclusions from this, but one thing that is clear is that the system-wide approach does not have a significant impact on compile time. > Obviously, people are free to have different opinions, and I wouldn't want > to start another Eiffel/Ada flamefest, so I generally avoid posting my > opinion on the Eiffel ng. That's probably the safest thing to do. :-) -PD -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-10 0:00 ` doylep @ 1998-08-10 0:00 ` Brian Rogoff 1998-08-10 0:00 ` John Volan ` (2 more replies) 1998-08-11 0:00 ` Don Harrison 1998-08-13 0:00 ` Robert A Duff 2 siblings, 3 replies; 138+ messages in thread From: Brian Rogoff @ 1998-08-10 0:00 UTC (permalink / raw) On Mon, 10 Aug 1998 doylep@ecf.toronto.edu wrote: > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > Call the steering wheel Steering_Wheel, and call the type something like > > Steering_Wheel_Type, or Steering_Wheel_T. Personally, I like type names > > and variable names to be lexically distinguished, so the EuLisp/Dylan > > convention, which would be to name it something like <SteeringWheel>, > > would be my choice if I could do it all myself, but I don't think the > > _Type convention is bad at all, and its used widely in my Ada reference > > of choice (Ada as a Second Language). > > The Eiffel convention is to use uppercase for class names and lowercase for > feature names. Does this fit the bill? Some compilers won't even accept > source code that does not follow this convention, so other programmers not > conforming is not an issue. Well, its definitely lexically distinguishable in a case sensitive language, but as I said earlier, I find it aesthetically unappealling to rely on case alone for the distinction. Even in C and Java, I use more than case to distinguish. Personally, I don't mind a little redundancy, and I find all of this talk of "noise" in the type name really funny, as though its somehow really difficult for the reader to deal with this _Type business. However, as I also said, if I were to use Eiffel or a similar language long enough, I'm pretty sure I'd get used to it, even if I don't like that convention now. > > If you want to talk about having to create contrived names, be careful, > > Eiffel doesn't have overloading, which is far worse IMO. Apparently the > > Sather designers agreed, when they decided to "fix" Eiffel, they added > > overloading. Other languages, like OCaml, do away with most of the need > > to name types altogether, so the antiredundantists should consider such > > languages before disparaging the Ada way in deference to Eiffel way. > > Perhaps, but preventing redundancy is still a good thing, so the fact that a > language is redundant in one sense doesn't change the fact that eliminating > redundancy in another sense is a Good Thing. You're absolutely correct here. However, I don't think Ada will change (in this regard) anytime to soon, nor will Eiffel adopt overloading, so I think if I have a choice, I find overloading to be a more useful feature in eliminating redundancy in name choice. If you really want to look at eliminating redundancy, look at languages which do are indentation sensitive (Python, Haskell, ...) and eliminate all of those noisy begin...end pairs. 1/2 :-) ... snip ... > > Fair enough. I don't like covariance either. But as for whole-program > analysis... > > First, this is not necessary if you're satisfied with some type checking being > done at runtime. And significantly less optimization too, at that point. > So the accurate assessment would be that whole-program > analysis is required for static type safety, rather than to make Eiffel usable > at all. If you are willing to forego static checking, why use Eiffel or Ada at all? > Second, SmallEiffel is a compiler which has dived whole-heartedly into a > system-wide approach, and as such is able to make *massive* optimisations > which produce excellent executables. Since the compiler is compiled by > itself, it makes use of these optimisations to provide system-wide > compilation which is of comparable speed to module-wise compilation systems. Nothing stops you from getting the best of both worlds in Ada, since nothing in Ada precludes you from doing whole program analysis, that is assuming you have the whole program to analyze. In Eiffel, you have to do whole program analysis to get type safety, and I don't believe that any Eiffel compiler even does the entire analysis (system level validity checking, or now polymorphic catcall checking?), so I just can't see this as being an Eiffel advantage. Just for my education, do any current Eiffel compilers actually do all of the analysis? > In fact, because SmallEiffel compiles to C, it is possible to compare the > system-wide approach to the module-wise approach directly, and the Eiffel-to-C > phase of compilation is invariably faster than the C-to-native phase, often by > an order of magnitude, despite the fact that the C-to-native phase only > compiles the portions that have changed. It is dangerous to draw too many > conclusions from this, but one thing that is clear is that the system-wide > approach does not have a significant impact on compile time. Sorry, I don't believe it. A language with separately compiled modules will always have an advantage here; as I said above, you could apply the same technology to Ada or a similar language, and you'd be guaranteed type safety too, whereas with Eiffel you really have to check the whole program or defer some checks until run time. Seems to defeat the purpose of static checking at that point. -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-10 0:00 ` Brian Rogoff @ 1998-08-10 0:00 ` John Volan 1998-08-10 0:00 ` John Volan 1998-08-11 0:00 ` doylep 2 siblings, 0 replies; 138+ messages in thread From: John Volan @ 1998-08-10 0:00 UTC (permalink / raw) Brian Rogoff wrote: > > Well, its definitely lexically distinguishable in a case sensitive > language, but as I said earlier, I find it aesthetically unappealling to ^^^^^^^^^^^^^^^^^^^^^^^^^^ > rely on case alone for the distinction. Even in C and Java, I use > more than case to distinguish. Personally, I don't mind a little > redundancy, and I find all of this talk of "noise" in the type name really > funny, as though its somehow really difficult for the reader to deal with > this _Type business. Although I don't count myself among them [*], I'm pretty sure that the people who object to the "_Type" convention in Ada do so not because they feel that this "noise" somehow reduces understandability, but rather purely as a matter of taste. To them, having a type name _say_ that it is a type name, when this fact can simply be deduced from context, or by looking up the declaration, amounts to "catering to the programming language". This seems to disturb their aesthetic sensibilities somehow -- just as relying on case distinctions seems to disturb your aesthetic sensibilities, Brian. [*] I should say, I don't object to "_Type" -- and indeed I advocate it -- if one is programming in Ada. It seems to be the best compromise given the properties of that language. On the other hand, if one is programming in Java, C++, Eiffel, or Smalltalk, I'd advocate exploiting case conventions for all they're worth, and don't bother with "_Type". > However, as I also said, if I were to use Eiffel or a similar language > long enough, I'm pretty sure I'd get used to it, even if I don't like > that convention now. Exactly. -- 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] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-10 0:00 ` Brian Rogoff 1998-08-10 0:00 ` John Volan @ 1998-08-10 0:00 ` John Volan 1998-08-11 0:00 ` doylep 2 siblings, 0 replies; 138+ messages in thread From: John Volan @ 1998-08-10 0:00 UTC (permalink / raw) Brian Rogoff wrote: > > Well, its definitely lexically distinguishable in a case sensitive > language, but as I said earlier, I find it aesthetically unappealling to ^^^^^^^^^^^^^^^^^^^^^^^^^^ > rely on case alone for the distinction. Even in C and Java, I use > more than case to distinguish. Personally, I don't mind a little > redundancy, and I find all of this talk of "noise" in the type name really > funny, as though its somehow really difficult for the reader to deal with > this _Type business. Although I don't count myself among them [*], I'm pretty sure that the people who object to the "_Type" convention in Ada do so not because they feel that this "noise" somehow reduces understandability, but rather purely as a matter of taste. To them, having a type name _say_ that it is a type name, when this fact can simply be deduced from context, or by looking up the declaration, amounts to "catering to the programming language". This seems to disturb their aesthetic sensibilities somehow -- just as relying on case distinctions seems to disturb your aesthetic sensibilities, Brian. [*] I should say, I don't object to "_Type" -- and indeed I advocate it -- if one is programming in Ada. It seems to be the best compromise given the properties of that language. On the other hand, if one is programming in Java, C++, Eiffel, or Smalltalk, I'd advocate exploiting case conventions for all they're worth, and don't bother with "_Type". > However, as I also said, if I were to use Eiffel or a similar language > long enough, I'm pretty sure I'd get used to it, even if I don't like > that convention now. Exactly. -- 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] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-10 0:00 ` Brian Rogoff 1998-08-10 0:00 ` John Volan 1998-08-10 0:00 ` John Volan @ 1998-08-11 0:00 ` doylep 1998-08-11 0:00 ` Brian Rogoff 2 siblings, 1 reply; 138+ messages in thread From: doylep @ 1998-08-11 0:00 UTC (permalink / raw) In article <Pine.BSF.3.96.980810163352.29141A-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > On Mon, 10 Aug 1998 doylep@ecf.toronto.edu wrote: > > > > The Eiffel convention is to use uppercase for class names and lowercase for > > feature names. Does this fit the bill? Some compilers won't even accept > > source code that does not follow this convention, so other programmers not > > conforming is not an issue. > > Well, its definitely lexically distinguishable in a case sensitive > language, but as I said earlier, I find it aesthetically unappealling to > rely on case alone for the distinction. Well, it would be compiler-enforced case sensitivity *in addition* to different namespaces, but I think I get your point. > However, as I also said, if I were to use Eiffel or a similar language > long enough, I'm pretty sure I'd get used to it, even if I don't like > that convention now. Right. Fair enough. > If you really want to look at eliminating redundancy, look at languages > which do are indentation sensitive (Python, Haskell, ...) and eliminate > all of those noisy begin...end pairs. 1/2 :-) True. I've seen those, and I probably find that about as distasteful as you do Eiffel's conventions. However, as you say, I'm sure I'd get used to it. > > Fair enough. I don't like covariance either. But as for whole-program > > analysis... > > > > First, this is not necessary if you're satisfied with some type checking > > being done at runtime. > > And significantly less optimization too, at that point. Well, I'm not sure that's the case. All that is needed is a check to make sure that an object conforms; after that, it can be assumed that it conforms, with all the implications that would have arisen if that could have been proven at compile time. Besides, because I dislike covariance, I don't use it, so I don't pay any penalty for it. > If you are willing to forego static checking, why use Eiffel or Ada at > all? Hey, let's be fair here; we're not really foregoing static checking. You can have it if you don't use covariance. And if you do use covariance, well then yes, you are foregoing static checking in those cases, so it's a tradeoff. However, even in such cases, Eiffel still offers the advantages of Design By Contract, plus its nice data type and algorithm libraries, which may be enough to make one want to use Eiffel even without 100% static type checking. > > Second, SmallEiffel is a compiler which has dived whole-heartedly into a > > system-wide approach, and as such is able to make *massive* optimisations > > which produce excellent executables. Since the compiler is compiled by > > itself, it makes use of these optimisations to provide system-wide > > compilation which is of comparable speed to module-wise compilation systems. > > Nothing stops you from getting the best of both worlds in Ada, since > nothing in Ada precludes you from doing whole program analysis, that is > assuming you have the whole program to analyze. True. My real point is a much weaker one: simply that such compilers for Eiffel actually *exist* whereas (correct me if I'm wrong) they don't exist for Ada or any other language. In fact, the people who wrote the SmallEiffel compiler pioneered some techniques in system-wide optimizations, so I can say with some certainty that these things are not in any other compilers. Certainly the issue of what compilers *could* do is much more nebulous, and IMHO less relevant to language choices than what compilers *actually* do. (This is a double-edged sword, of course, since it cancels my point that Eiffel compilers *could* do system validity checks. :-) > In Eiffel, you have to do > whole program analysis to get type safety, and I don't believe that any > Eiffel compiler even does the entire analysis (system level validity > checking, or now polymorphic catcall checking?), so I just can't see > this as being an Eiffel advantage. Just for my education, do any current > Eiffel compilers actually do all of the analysis? I believe there are no such compilers currently available. Don't get me wrong: I don't think the fact that Eiffel *requires* system validity checking is a good thing. Personally, I'd like to see covariance and feature hiding banished. > > In fact, because SmallEiffel compiles to C, it is possible to compare the > > system-wide approach to the module-wise approach directly, and the Eiffel-to-C > > phase of compilation is invariably faster than the C-to-native phase, often by > > an order of magnitude, despite the fact that the C-to-native phase only > > compiles the portions that have changed. It is dangerous to draw too many > > conclusions from this, but one thing that is clear is that the system-wide > > approach does not have a significant impact on compile time. > > Sorry, I don't believe it. A language with separately compiled modules > will always have an advantage here; as I said above, you could apply the > same technology to Ada or a similar language, and you'd be guaranteed type > safety too, whereas with Eiffel... [points already covered above] Well, separately-compiled units are largely an illusion anyway, since any build process (that I'm aware of) requires at least one step which is system-wide. With C, for instance, the link phase is system-wide, and so is the dependency-checking phase (say, with makefiles). So separate compilation does not provide a different order of complexity versus system-wide approaches. At best it has a smaller multiplier; in the case of SmallEiffel vs. C, it has been my experience that even this is not the case. -PD -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-11 0:00 ` doylep @ 1998-08-11 0:00 ` Brian Rogoff 1998-08-13 0:00 ` Robert A Duff 0 siblings, 1 reply; 138+ messages in thread From: Brian Rogoff @ 1998-08-11 0:00 UTC (permalink / raw) I think we've strayed far from the naming discussion, so maybe we should continue this on comp.lang.misc, since some other languages besides Ada are being discussed, or privately via e-mail. I have no interest in expanding the newsgroups line, and I'm beginning to think that crossposting in general is a questionable practice. On Tue, 11 Aug 1998 doylep@ecf.toronto.edu wrote: > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > If you really want to look at eliminating redundancy, look at languages > > which do are indentation sensitive (Python, Haskell, ...) and eliminate > > all of those noisy begin...end pairs. 1/2 :-) > > True. I've seen those, and I probably find that about as distasteful as you > do Eiffel's conventions. However, as you say, I'm sure I'd get used to it. Indeed, you may even find that here are certain advantages to this choice. I found it rather unnerving at first myself. I don't have a lot of experience with these languages, so I can't say how I'll feel in a few years time. My Python programs have tended to be small, and Haskell is more of an academic curiosity to me than a language that I'd use for real programming. Maybe one day... > > > Fair enough. I don't like covariance either. But as for whole-program > > > analysis... > > > > > > First, this is not necessary if you're satisfied with some type checking > > > being done at runtime. > > > > And significantly less optimization too, at that point. > > Well, I'm not sure that's the case. All that is needed is a check to make > sure that an object conforms; after that, it can be assumed that it conforms, > with all the implications that would have arisen if that could have been > proven at compile time. I think if you keep type information around at run time, you've sacrificed some optimization, right? > Besides, because I dislike covariance, I don't use it, so I don't pay any > penalty for it. But you also can't use anyone else's Eiffel program if they don't share your dislike, else you'll pay the penalty. It almost sounds like you were a Sather user, or at least that you'd have really liked Sather. > > If you are willing to forego static checking, why use Eiffel or Ada at > > all? > > Hey, let's be fair here; we're not really foregoing static checking. You can > have it if you don't use covariance. And if you do use covariance, well then > yes, you are foregoing static checking in those cases, so it's a tradeoff. > However, even in such cases, Eiffel still offers the advantages of Design By > Contract, I agree that Eiffel's built in assertion mechanisms are very nice, and more powerful than what we have in Ada. I also think that external tools could provide many of the same advantages, and maybe even provide more. But I accept that my statement is unfair, and you may like Eiffel at many levels. > plus its nice data type and algorithm libraries, which may be enough > to make one want to use Eiffel even without 100% static type checking. Eiffel lacks the ability to do system level programming (low level mucking) so I'm not sure that its data types are really more powerful than what you get in Ada. > > Nothing stops you from getting the best of both worlds in Ada, since > > nothing in Ada precludes you from doing whole program analysis, that is > > assuming you have the whole program to analyze. > > True. My real point is a much weaker one: simply that such compilers for > Eiffel actually *exist* whereas (correct me if I'm wrong) they don't exist > for Ada or any other language. In fact, the people who wrote the SmallEiffel > compiler pioneered some techniques in system-wide optimizations, so I can say > with some certainty that these things are not in any other compilers. The Scheme compiler Stalin, at http://www.neci.nj.nec.com/homepages/qobi/software.html does extensive system wide optimizations, and compiles Scheme down to some mighty fast C. Whether other compilers do exactly what SmallEiffel does is probably not relevant, Eiffel needs certain optimizations to be fast, Scheme needs others, and Ada probably others still. I don't know of any Ada compilers which do whole program optimization. > Certainly the issue of what compilers *could* do is much more nebulous, and > IMHO less relevant to language choices than what compilers *actually* do. Very true, and also relevant to my comment about DBC as an external tool for Ada; since it hasn't been done I shouldn't claim that the possibility of doing negates the Eiffel advantage here, so I don't. > I believe there are no such compilers currently available. > > Don't get me wrong: I don't think the fact that Eiffel *requires* system > validity checking is a good thing. Personally, I'd like to see covariance and > feature hiding banished. Have you looked at Sather? It looks like what you want, though it seems moribund now. > > Sorry, I don't believe it. A language with separately compiled modules > > will always have an advantage here; as I said above, you could apply the > > same technology to Ada or a similar language, and you'd be guaranteed type > > safety too, whereas with Eiffel... [points already covered above] > > Well, separately-compiled units are largely an illusion anyway, since any > build process (that I'm aware of) requires at least one step which is > system-wide. With C, for instance, the link phase is system-wide, and so is > the dependency-checking phase (say, with makefiles). Sure, but different groups can develop independent modules in Ada, compile pieces independently, and link them together in the end and be sure that the result contains no type violations (there could be other violations, like range violations, which would correspond to violated assertions in Eiffel). This is not true of Eiffel. -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-11 0:00 ` Brian Rogoff @ 1998-08-13 0:00 ` Robert A Duff 1998-08-13 0:00 ` Brian Rogoff 1998-09-01 0:00 ` Matthew Heaney 0 siblings, 2 replies; 138+ messages in thread From: Robert A Duff @ 1998-08-13 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> writes: > I think if you keep type information around at run time, you've sacrificed > some optimization, right? I don't think so. For example, consider "Mumble(T'Class(X));" in Ada, or X.Mumble in Eiffel. Both dispatch to the appropriate implementation of Mumble at run time, and both need to have "type information" around at run time to do so. If that type info weren't automatically kept around, the programmer would have to keep that same information explicitly. Note that the type info isn't being used here to perform run-time type checking; in both languages, there's guaranteed to be an appropriate Mumble to call. > I agree that Eiffel's built in assertion mechanisms are very nice, and > more powerful than what we have in Ada. I also think that external tools > could provide many of the same advantages, and maybe even provide more. I'd be interested in seeing a design for such external tools. > Sure, but different groups can develop independent modules in Ada, compile > pieces independently, and link them together in the end and be sure that > the result contains no type violations (there could be other violations, > like range violations, which would correspond to violated assertions in > Eiffel). This is not true of Eiffel. It seems sort of silly to say, "Language X catches all *type* errors at compile time, but of course there are other errors that are caught only at run time", since the language definition defines what's a "type error" and what's an "other error". Eg Ada catches variant record errors at run time. One could reasonably call those "type errors", but the language definition says they're merely "constraint check failures". I can easily define a language that catches *all* type errors at compile time, merely by defining "type error" to match what happens to be caught at compile time. Some folks would consider "divide by zero" to be a type error. But most languages catch it at run time. I could force it to be caught at compile time, but it might not improve the programming language. - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-13 0:00 ` Robert A Duff @ 1998-08-13 0:00 ` Brian Rogoff 1998-09-01 0:00 ` Matthew Heaney 1 sibling, 0 replies; 138+ messages in thread From: Brian Rogoff @ 1998-08-13 0:00 UTC (permalink / raw) On Thu, 13 Aug 1998, Robert A Duff wrote: > Brian Rogoff <bpr@shell5.ba.best.com> writes: > > > I think if you keep type information around at run time, you've sacrificed > > some optimization, right? > > I don't think so. For example, consider "Mumble(T'Class(X));" in Ada, > or X.Mumble in Eiffel. Both dispatch to the appropriate implementation > of Mumble at run time, and both need to have "type information" around > at run time to do so. But if T'Class(X), or X, can be determined to only be of one type by the compiler, keeping the tag around at run time is potentially less optimal than eliminating it. Thats what I was talking about, eliminating all of the tags that you can, rather tthan schlepping them around. > > I agree that Eiffel's built in assertion mechanisms are very nice, and > > more powerful than what we have in Ada. I also think that external tools > > could provide many of the same advantages, and maybe even provide more. > > I'd be interested in seeing a design for such external tools. The Larch toolkit is one attempt, though it seems that there is no Larch for Ada 95. LCLint is pretty useful for C programs, though I haven't used it for large (> 100KLOC of C being large) programs. Anna was also an attempt, long dead by now. Maybe a big problem of Ada is that it is good enough at eliminating many problems that noone feels the effort of going further is worth it, unlike C, or "the squeaky wheel gets the grease". More likely is that Ada is not popular enough to justify the investment. > > Sure, but different groups can develop independent modules in Ada, compile > > pieces independently, and link them together in the end and be sure that > > the result contains no type violations (there could be other violations, > > like range violations, which would correspond to violated assertions in > > Eiffel). This is not true of Eiffel. > > It seems sort of silly to say, "Language X catches all *type* errors at > compile time, but of course there are other errors that are caught only > at run time", since the language definition defines what's a "type > error" and what's an "other error". Eg Ada catches variant record > errors at run time. One could reasonably call those "type errors", but > the language definition says they're merely "constraint check failures". Fair enough. However, if you accept Eiffel's own definition of what its types are (I'm not talking about assertion violations), then Eiffel is not statically type safe in any realistic sense, since there is not now and has never been an Eiffel compiler which does full type checking of an Eiffel program at compile time. Eiffel advocates will claim its not important, and that serious users don't complain about this, but hey, serious users of Smalltalk and CLOS don't complain that their lack of static typing is a practical problem either, quite the opposite, they'll claim it leads to fewer bugs. > I can easily define a language that catches *all* type errors at compile > time, merely by defining "type error" to match what happens to be caught > at compile time. I still think constraint violations are more like assertion violations than type errors, but you're entitled to your opinion of course, and can define things as you like. -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-13 0:00 ` Robert A Duff 1998-08-13 0:00 ` Brian Rogoff @ 1998-09-01 0:00 ` Matthew Heaney 1998-09-01 0:00 ` Dale Stanbrough 1 sibling, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-09-01 0:00 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: > > I agree that Eiffel's built in assertion mechanisms are very nice, and > > more powerful than what we have in Ada. I also think that external tools > > could provide many of the same advantages, and maybe even provide more. > > I'd be interested in seeing a design for such external tools. Whatever happened to ANNA? ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-01 0:00 ` Matthew Heaney @ 1998-09-01 0:00 ` Dale Stanbrough 1998-09-01 0:00 ` Matthew Heaney 0 siblings, 1 reply; 138+ messages in thread From: Dale Stanbrough @ 1998-09-01 0:00 UTC (permalink / raw) Matthew Heaney wrote: "Whatever happened to ANNA?" Not much. It just sits quietly in a dusty corner of a hard disc drive at Stanford, waiting for someone to update it to Ada95, and use ASIS as the parsing engine. Dale ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-01 0:00 ` Dale Stanbrough @ 1998-09-01 0:00 ` Matthew Heaney 1998-09-01 0:00 ` Bob Collins 1998-09-04 0:00 ` John G. Volan 0 siblings, 2 replies; 138+ messages in thread From: Matthew Heaney @ 1998-09-01 0:00 UTC (permalink / raw) dale@cs.rmit.edu.au (Dale Stanbrough) writes: > Matthew Heaney wrote: > > "Whatever happened to ANNA?" > > > Not much. It just sits quietly in a dusty corner of a hard disc > drive at Stanford, waiting for someone to update it to Ada95, and > use ASIS as the parsing engine. I seems like this would be the idle environment-based tool to use to add pre- and postcondition checks to the language. You seem to know something about what's under the hood. How much effort are we talking about to make the update happen? Is is a one-person job part time? Full time? ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-01 0:00 ` Matthew Heaney @ 1998-09-01 0:00 ` Bob Collins 1998-09-02 0:00 ` Matthew Heaney 1998-09-04 0:00 ` John G. Volan 1 sibling, 1 reply; 138+ messages in thread From: Bob Collins @ 1998-09-01 0:00 UTC (permalink / raw) In article <m3r9xwocgy.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: [about Anna] > I seems like this would be the idle environment-based tool to use to add > pre- and postcondition checks to the language. Idle because it's not being used? -- Bob Collins <mailto:collins@cs.wm.edu> <http://ratbert.cs.wm.edu> ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-01 0:00 ` Bob Collins @ 1998-09-02 0:00 ` Matthew Heaney 0 siblings, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-09-02 0:00 UTC (permalink / raw) collins@cs.wm.edu (Bob Collins) writes: > > I seems like this would be the idle environment-based tool to use to add > > pre- and postcondition checks to the language. > > Idle because it's not being used? Oops! Fast but sloppy fingers I'm afraid. I meant "ideal." ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-01 0:00 ` Matthew Heaney 1998-09-01 0:00 ` Bob Collins @ 1998-09-04 0:00 ` John G. Volan 1 sibling, 0 replies; 138+ messages in thread From: John G. Volan @ 1998-09-04 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > dale@cs.rmit.edu.au (Dale Stanbrough) writes: > > > Matthew Heaney wrote: > > > > "Whatever happened to ANNA?" > > > > > > Not much. It just sits quietly in a dusty corner of a hard disc > > drive at Stanford, waiting for someone to update it to Ada95, and > > use ASIS as the parsing engine. > > I seems like this would be the idle environment-based tool to use to add > pre- and postcondition checks to the language. "Idle"? Matt, I think your Freudian slip is showing... ;-) -- indexing description: "Signatures for John Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %uniform access, generics, true MI, feature adaptation, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-10 0:00 ` doylep 1998-08-10 0:00 ` Brian Rogoff @ 1998-08-11 0:00 ` Don Harrison 1998-08-11 0:00 ` Pat Rogers 1998-08-13 0:00 ` Robert A Duff 2 siblings, 1 reply; 138+ messages in thread From: Don Harrison @ 1998-08-11 0:00 UTC (permalink / raw) Brian Rogoff wrote: :Thanks for bringing this back to c.l.a, Patrick. I was loathe to respond :to this in c.l.e., as I remember several language wars starting from :c.l.ada/eiffel crossposting, and I just don't care for them. BTW, I cross-posted because Eiffel was being discussed and others (Patrick, in this case) may have wanted to participate. My intention wasn't to re-ignite a language war. I don't have the time or inclination to participate in one. Presumably, you think it's clearer, in Ada, if variables and types have different identifiers. That may be true and the decision to require this a language rule may be the right one for Ada. For Eiffel, I think allowing use of the same identifier is the right policy as the simpler syntax is unlikely to cause confusion. Don. Don Harrison donh at syd.csa.com.au ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-11 0:00 ` Don Harrison @ 1998-08-11 0:00 ` Pat Rogers 1998-08-11 0:00 ` Don Harrison 0 siblings, 1 reply; 138+ messages in thread From: Pat Rogers @ 1998-08-11 0:00 UTC (permalink / raw) Don Harrison wrote in message ... >Brian Rogoff wrote: > >:Thanks for bringing this back to c.l.a, Patrick. I was loathe to respond >:to this in c.l.e., as I remember several language wars starting from >:c.l.ada/eiffel crossposting, and I just don't care for them. > >BTW, I cross-posted because Eiffel was being discussed and others >(Patrick, in this case) may have wanted to participate. My intention >wasn't to re-ignite a language war. I don't have the time or inclination >to participate in one. I was surprised to see mention of a c.l.ada/eiffel war. I wasn't following all such threads terribly closely, partly because of the venom oozing out of the C++/Eiffel wars. I've found the Ada/Eiffel discussions polite and very informative, and hope they continue when sufficient interest exists. -- pat Patrick Rogers progers@acm.org http://www.neosoft.com/~progers ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-11 0:00 ` Pat Rogers @ 1998-08-11 0:00 ` Don Harrison 1998-09-01 0:00 ` Matthew Heaney 0 siblings, 1 reply; 138+ messages in thread From: Don Harrison @ 1998-08-11 0:00 UTC (permalink / raw) Pat Rogers wrote: :Don Harrison wrote in message ... :>Brian Rogoff wrote: :> :>:Thanks for bringing this back to c.l.a, Patrick. I was loathe to respond :>:to this in c.l.e., as I remember several language wars starting from :>:c.l.ada/eiffel crossposting, and I just don't care for them. :> :>BTW, I cross-posted because Eiffel was being discussed and others :>(Patrick, in this case) may have wanted to participate. My intention :>wasn't to re-ignite a language war. I don't have the time or inclination :>to participate in one. : : :I was surprised to see mention of a c.l.ada/eiffel war. I wasn't following all :such threads terribly closely, partly because of the venom oozing out of the :C++/Eiffel wars. I've found the Ada/Eiffel discussions polite and very :informative, and hope they continue when sufficient interest exists. I agree the current tenor of discussion between Eiffel and Ada advocates is positive. There have been some heated debates in the past which haven't been too constructive. My own criticism of Ada has probably led some to believe I have no appreciation of the language. This isn't true. I happen to prefer Eiffel, though I would choose Ada in preference to C++ any day. Eiffel and Ada advocates are often passionate about their favourite language and crossposting carries the risk of sparking a bun-fight. However, it can also help clear up misconceptions about each. Don. Don Harrison donh at syd.csa.com.au ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-11 0:00 ` Don Harrison @ 1998-09-01 0:00 ` Matthew Heaney 0 siblings, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-09-01 0:00 UTC (permalink / raw) nospam@thanks.com.au (Don Harrison) writes: > Eiffel and Ada advocates are often passionate about their favourite > language and crossposting carries the risk of sparking a bun-fight. > However, it can also help clear up misconceptions about each. This was indeed the case on comp.object recently. I was able to show some Eiffel guys how importing an operation as a generic formal subprogram eliminates the coupling that would occur by using multiple inheritance to compose abstractions. All and all, I'd say USENET is worth it. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-10 0:00 ` doylep 1998-08-10 0:00 ` Brian Rogoff 1998-08-11 0:00 ` Don Harrison @ 1998-08-13 0:00 ` Robert A Duff 1998-08-13 0:00 ` Brian Rogoff 1998-08-14 0:00 ` Don Harrison 2 siblings, 2 replies; 138+ messages in thread From: Robert A Duff @ 1998-08-13 0:00 UTC (permalink / raw) doylep@ecf.toronto.edu writes: > Yes, that's the same reason I am usually too afraid to venture into c.l.a. > :-) I wish we could all discuss the advantages and disadvantages of specific features of programming languages, without getting into the "My Language is better than Your Language" mode. Oh, well. > The Eiffel convention is to use uppercase for class names and lowercase for > feature names. Does this fit the bill? Some compilers won't even accept > source code that does not follow this convention, so other programmers not > conforming is not an issue. The "some compilers" above introduces another point: Shouldn't the language standard specify one way or the other?! > > Obviously, people are free to have different opinions, and I wouldn't want > > to start another Eiffel/Ada flamefest, so I generally avoid posting my > > opinion on the Eiffel ng. > > That's probably the safest thing to do. :-) Sigh. ;-) - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-13 0:00 ` Robert A Duff @ 1998-08-13 0:00 ` Brian Rogoff 1998-08-15 0:00 ` Don Harrison 1998-08-14 0:00 ` Don Harrison 1 sibling, 1 reply; 138+ messages in thread From: Brian Rogoff @ 1998-08-13 0:00 UTC (permalink / raw) On Thu, 13 Aug 1998, Robert A Duff wrote: > I wish we could all discuss the advantages and disadvantages of specific > features of programming languages, without getting into the "My Language > is better than Your Language" mode. But the appropriate place to discuss such things is probably comp.lang.misc, or comp.object, or comp.software-eng, or ... Crossposted threads, even very polite ones, tend to be noise for people who, for example, only want to read about Ada on the Ada ng, or Eiffel on the Eiffel ng, or Lisp on the Lisp ng, etc. I'm sure many people in the Eiffel ng feel the same way, and just aren't interested in Ada, or Forth, or Python. (Whew, lots of or-ing in this post!) -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-13 0:00 ` Brian Rogoff @ 1998-08-15 0:00 ` Don Harrison 1998-08-15 0:00 ` Jean-Pierre Rosen 0 siblings, 1 reply; 138+ messages in thread From: Don Harrison @ 1998-08-15 0:00 UTC (permalink / raw) Brian Rogoff wrote (in comp.lang.ada): : .. I'm sure many people in the :Eiffel ng feel the same way, and just aren't interested in Ada, .. This may come as a shock to you, Brian, but the number of cross-posted Eiffel-Ada threads in the last few years has increased interest in Ada among members of the Eiffel community. From your perspective, that can't be a bad thing, can it? Interest in Eiffel among members of the Ada community has also increased and we consider that a good thing. :) These discussions have allowed each side to appreciate what the other language has to contribute to software engineering and has dispelled at least some of the inevitable misconceptions that come with looking from the other side of the fence. I think Eiffel and Ada developers can learn a lot from each other and hope that polite cross-posted discussions continue. Anyone who doesn't want to contribute positively is welcome to keep quiet. Don. Don Harrison donh at syd.csa.com.au ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-15 0:00 ` Don Harrison @ 1998-08-15 0:00 ` Jean-Pierre Rosen 1998-08-18 0:00 ` Don Harrison 0 siblings, 1 reply; 138+ messages in thread From: Jean-Pierre Rosen @ 1998-08-15 0:00 UTC (permalink / raw) Don Harrison a �crit dans le message ... [...] >I think Eiffel and Ada developers can learn a lot from each other and >hope that polite cross-posted discussions continue. Anyone who doesn't >want to contribute positively is welcome to keep quiet. > 2 cts of information: There IS a connection between Eiffel and Ada. The syntax of Eiffel was inspired by Ada, and B. Meyer was the founder of the Ada group at AFCET (which later became Ada-France). ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-15 0:00 ` Jean-Pierre Rosen @ 1998-08-18 0:00 ` Don Harrison 0 siblings, 0 replies; 138+ messages in thread From: Don Harrison @ 1998-08-18 0:00 UTC (permalink / raw) Jean-Pierre Rosen wrote: :There IS a connection between Eiffel and Ada. The syntax of Eiffel was :inspired by Ada, and B. Meyer was the founder of the Ada group at AFCET :(which later became Ada-France). Yes, the influence of Ada on the design of Eiffel is unmistakeable. Interestingly, no syntax from C found its way into Eiffel. .. which isn't so surprising. :) Don. Don Harrison donh at syd.csa.com.au ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-13 0:00 ` Robert A Duff 1998-08-13 0:00 ` Brian Rogoff @ 1998-08-14 0:00 ` Don Harrison 1998-08-17 0:00 ` doylep 1 sibling, 1 reply; 138+ messages in thread From: Don Harrison @ 1998-08-14 0:00 UTC (permalink / raw) Bob Duff wrote: :doylep@ecf.toronto.edu writes: :> The Eiffel convention is to use uppercase for class names and lowercase for :> feature names. [..] Some compilers won't even accept :> source code that does not follow this convention .. : :The "some compilers" above introduces another point: Shouldn't the :language standard specify one way or the other?! Standard Eiffel is case-insensitive. I'm not sure which compiler Patrick is referring to, but if it enforces any case convention, it's a non-compliant implementation. Don. Don Harrison donh at syd.csa.com.au ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-14 0:00 ` Don Harrison @ 1998-08-17 0:00 ` doylep 1998-08-19 0:00 ` Don Harrison 0 siblings, 1 reply; 138+ messages in thread From: doylep @ 1998-08-17 0:00 UTC (permalink / raw) In article <ExnKrB.G63@syd.csa.com.au>, nospam@thanks.com.au wrote: > > Standard Eiffel is case-insensitive. Indeed, this is correct. > I'm not sure which compiler Patrick > is referring to, but if it enforces any case convention, it's a > non-compliant implementation. SmallEiffel generates warnings for identifiers which do not conform to the standard Eiffel conventions for upper/lower case. (Incidentally, by default, SmallEiffel is also case sensitive; this is disabled with a compiler flag. I'm not sure why it was done this way.) -PD -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-17 0:00 ` doylep @ 1998-08-19 0:00 ` Don Harrison 0 siblings, 0 replies; 138+ messages in thread From: Don Harrison @ 1998-08-19 0:00 UTC (permalink / raw) Patrick Doyle wrote: :In article <ExnKrB.G63@syd.csa.com.au>, : nospam@thanks.com.au wrote: :> :> Standard Eiffel is case-insensitive. : :Indeed, this is correct. Thanks for confirming that for me. :) Don. Don Harrison donh at syd.csa.com.au ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-07 0:00 ` Brian Rogoff 1998-08-08 0:00 ` Matthew Heaney 1998-08-10 0:00 ` doylep @ 1998-08-12 0:00 ` Don Harrison 2 siblings, 0 replies; 138+ messages in thread From: Don Harrison @ 1998-08-12 0:00 UTC (permalink / raw) Brian Rogoff wrote (in comp.lang.ada): :The truth is I don't think I'll use Eiffel again, because I don't think :its a very good language design. I think OO is overrated, and languages :that try to enforce OO as the *only* programming tool are not for me. You do realise, of course, that you can use Eiffel in a non-OO way if you so choose (no inheritance, polymorphism; use selective export to co-encapsulate abstractions etc.) but it would be a bit like using the nail file of a Swiss Army knife for cutting, opening tin cans etc. when those respective attachments are also available. :I like Eiffel's assertion mechanisms (though I'm not sure they belong in the :language or would be better left as a tool) but I think its type system is :hopelessly broken, it *requires* whole-program analysis due to covariance; :bye-bye separate compilation! I've yet to come across a serious Eiffel user who bemoans the fact that system validity is currently a runtime phenomenon. Those complaining invariably aren't Eiffel users. Don. Don Harrison donh at syd.csa.com.au ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-07 0:00 ` doylep 1998-08-07 0:00 ` Brian Rogoff @ 1998-08-08 0:00 ` Matthew Heaney 1998-08-08 0:00 ` John G. Volan 1998-08-11 0:00 ` doylep 1 sibling, 2 replies; 138+ messages in thread From: Matthew Heaney @ 1998-08-08 0:00 UTC (permalink / raw) doylep@ecf.toronto.edu writes: > 2. It allows you to avoid contrivances by permitting things like this: > > class CAR > > feature > steering_wheel : STEERING_WHEEL > > end > > What else are you going to call the steering wheel? A > direction_control_device? I think any other name would be contrived. I usually qualify auxiliary types with the name of the "main" type, so I probably would have named the type Car_Steering_Wheel, and the object Steering_Wheel. package Cars is type Car_Steering_Wheel is ...; type Car is tagged record Steering_Wheel : Car_Steering_Wheel; end record; This is the convention used in package Text_IO, for type File_Mode. This is another reason why use clauses are safe. The naming convention makes it obvious that type Car_Steering_Wheel is declared package Cars. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-08 0:00 ` Matthew Heaney @ 1998-08-08 0:00 ` John G. Volan 1998-08-09 0:00 ` Matthew Heaney 1998-08-11 0:00 ` doylep 1 sibling, 1 reply; 138+ messages in thread From: John G. Volan @ 1998-08-08 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > doylep@ecf.toronto.edu writes: > > > 2. It allows you to avoid contrivances by permitting things like this: > > > > class CAR > > > > feature > > steering_wheel : STEERING_WHEEL > > > > end > > > > What else are you going to call the steering wheel? A > > direction_control_device? I think any other name would be contrived. > > I usually qualify auxiliary types with the name of the "main" type, so I > probably would have named the type Car_Steering_Wheel, and the object > Steering_Wheel. > > package Cars is > > type Car_Steering_Wheel is ...; > > type Car is > tagged record > Steering_Wheel : Car_Steering_Wheel; > end record; > > This is the convention used in package Text_IO, for type File_Mode. > > This is another reason why use clauses are safe. The naming convention > makes it obvious that type Car_Steering_Wheel is declared package Cars. Matthew, you seem to be confusing P. Doyle's point. (You seem to have lost something in translation from Eiffel to Ada, not surprising.) I'm fairly certain that P. Doyle intended the "STEERING_WHEEL" type to be a primary type in its own right, declared within its own module, and not some auxiliary type subordinate to the "CAR" type, somehow declared within the same module. (In fact, since P.D.'s example was Eiffel, the "STEERING_WHEEL" type would _be_ its own module). So your answer begs the question: What, then, would you call an instance of the "CAR" type? In Eiffel, the answer is fairly simple: car : CAR The equivalent in Java would be: Car car; (Let's please assume that we're in some context where there is only one instance of the "CAR" type that happens to be of interest, so there's no particular reason to attach some modifying adjective that distinguishes that instance from any other instance of the "CAR" type. This is by no means a rare situation -- the above might be an argument to a method.) It's interesting to note that the reasons this works out are very different in Java as opposed to Eiffel: Java (like C++ and Smalltalk before it) is case-sensitive. This allows programmers to get the _effect_ of two namespaces, by adopting a naming convention in which a class name and a variable name may be the "same" identifier, but differing in case. In reality, the compiler considers "car" and "Car" to be two completely distinct identifiers. Java really has only one namespace (in any given scope), but this naming convention effectively segregates that namespace into two mutually-exclusive subsets. Since the convention follows a regular rule (class names initial uppercase, variable names initial lowercase), it is immediately obvious to the programmer's eye into which subset a given identifier falls. In Eiffel, the situation appears to be reversed: The compiler is case-insensitive, but there actually _are_ two namespaces for type names vs. entity names. (That's interesting to me -- I had not known that before.) So the Eiffel naming convention (type names all-uppercase; entity names all-lowercase or mixed case) is purely a cosmetic convenience for the human reader. To the compiler, "car" and "CAR" really _are_ the same identifier, but the syntactic context allows the compiler to distinguish which namespace to resolve the identifier against. Ada has only one namespace (within any given scope). Since Ada is also case-insensitive, the only recourse is to come up with completely different identifiers for a variable and for its type. But the only difference between a variable and its type is that the former is at a "base" level of abstraction, while the latter is at a "meta" level of abstraction. Otherwise, they're just two manifestations of a single "concept". The base/meta distinction is fairly subtle; people tend to want to gloss over it, and just use the same noun for both "car" as a variable, and "CAR" as a type. It seems to me that if one is forced to come up with distinct identifiers for a type and an (arbitrary) instance of that type, then the difference between the identifiers should reflect this base/meta distinction. Thus, the Cohen style: Car : Car_Type; In other words, the thing on the left hand side of the colon is a _car_, while the thing on the right hand side a _type_ (the "car" type). The old Booch style: The_Car : Car; also reflects this same base/meta distinction. Using the definite article in the variable name makes it clear that we're talking about a specific instance of the concept (at the "base" level of abstraction), whereas using the indefinite noun "Car" by itself indicates we're talking at a more abstract level (the "meta" level). It seems to me that any scheme that contrives different identifiers without playing into the base/meta distinction is an ad hoc scheme. Matthew, you seem to be advocating a variation on the "abbreviation" approach: Come up with some wordy phrase for a type name, and then arbitrarily lop off some part of that phrase to come up with a variable name. That seems ad hoc to me. If it was important enough to say, in a type name, that something is a "Car_Steering_Wheel" (as opposed to, perhaps, a "Truck_Steering_Wheel"), then why isn't it also important to say "Car_Steering_Wheel" in the variable name too? Why arbitrarily lop off the "Car_" part? On the other hand, if the "Car_" part is already understood (because the type is already nested inside a "Cars" package), then why bother with the "Car_" part in the first place, in the type name? Isn't that just noise? If the type name were only "Steering_Wheel", what would you propose lopping off from that to make the variable name? The "Steering_" part? Then why did we need to say "Steering_" in the type name? Isn't that just noise too? On the other hand, what if the car doesn't just have a steering wheel, but also has four drive wheels? Then don't we need to say "Steering_Wheel" and "Drive_Wheel", not only in the type names but also in the variable names too? What do we lop off where? And what do you propose we lop off of the type name "Car" to make a variable name? Alternatively, what "noise" word shall we tack onto the type name so we can then lop it off? A naming convention should be systematic, mechanical, predictable and transparent. That means that it should take NO THOUGHT to apply it, or to interpret the results. The argument that this limits a programmer's creativity is specious. There's plenty of opportunity for a software engineer to be creative just in coming up with concepts like "Car" or "Steering_Wheel" to program up. That's the real critical design step. Going on to split each of these into base-level variable names and meta-level type names should be a mechanical process, not something to waste time over -- either for the code-writer, or more importantly for the code-reader. IMHO, the styles that Java and Eiffel allow meet the criteria of being systematic, mechanical, etc. In Ada, Cohen and Booch styles (and Jean-Pierre Rosen's style, as a variation on Booch) also meet these criteria, although at the cost of adding systematic "noise" (i.e., "_Type" or "The_"). But I am at a loss to see how Heaney style would meet these criteria in the most general case. -- Signature volanSignature = new Signature ( /*name: */ "John G. Volan", /*employer: */ "Raytheon/TI 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, named parameter passing, etc...", /*disclaimer:*/ "These views not packaged in COM.ti.dseg.ac3i.*, " + "so loading them throws DontQuoteMeError. :-) " ); ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-08 0:00 ` John G. Volan @ 1998-08-09 0:00 ` Matthew Heaney 1998-08-10 0:00 ` John G. Volan 0 siblings, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-08-09 0:00 UTC (permalink / raw) "John G. Volan" <johnvolan@sprintmail.com> writes: > Matthew Heaney wrote: > > I usually qualify auxiliary types with the name of the "main" type, so I > > probably would have named the type Car_Steering_Wheel, and the object > > Steering_Wheel. > > > > package Cars is > > > > type Car_Steering_Wheel is ...; > > > > type Car is > > tagged record > > Steering_Wheel : Car_Steering_Wheel; > > end record; > > > > This is the convention used in package Text_IO, for type File_Mode. > > > > This is another reason why use clauses are safe. The naming convention > > makes it obvious that type Car_Steering_Wheel is declared package Cars. > > Matthew, you seem to be confusing P. Doyle's point. (You seem to have > lost something in translation from Eiffel to Ada, not surprising.) I'm > fairly certain that P. Doyle intended the "STEERING_WHEEL" type to be a > primary type in its own right, declared within its own module, and not > some auxiliary type subordinate to the "CAR" type, somehow declared > within the same module. (In fact, since P.D.'s example was Eiffel, the > "STEERING_WHEEL" type would _be_ its own module). Your point highlights a difference between the two languages. In Ada, it's very natural to declare related ("cohesive") types in a single module. I was proceeding under the assumption that steering wheel type didn't stand on its own; that it supported the larger car abstraction, and hence was declared in the car module. This is a very common idiom in Ada, where you have a single module that exports one or more primary ADTs, supplemented by auxiliary types that describe attributes of the primary abstraction(s). > So your answer begs the question: What, then, would you call an instance > of the "CAR" type? > > In Eiffel, the answer is fairly simple: > > car : CAR > > The equivalent in Java would be: > > Car car; > > (Let's please assume that we're in some context where there is only one > instance of the "CAR" type that happens to be of interest, so there's no > particular reason to attach some modifying adjective that distinguishes > that instance from any other instance of the "CAR" type. This is by no > means a rare situation -- the above might be an argument to a method.) If it's the root of a tagged type hierarchy, then I would call it Root_Car, just like they do in the RM (example: Root_Storage_Pool). > Ada has only one namespace (within any given scope). Since Ada is also > case-insensitive, the only recourse is to come up with completely > different identifiers for a variable and for its type. This is indeed the case. Which is why I think it's confusing to use expanded name notation to differentiate between otherwise identical names for object and type. Use different identifiers for each. > It seems to me that if one is forced to come up with distinct > identifiers for a type and an (arbitrary) instance of that type, then > the difference between the identifiers should reflect this base/meta > distinction. Thus, the Cohen style: > > Car : Car_Type; Sometimes, if there really is no suitable adjective to describe the type (or, you're just not feeling too creative that day), then you do have to use _Type as the type name. But I find those times to be rare. > The old Booch style: > > The_Car : Car; > > also reflects this same base/meta distinction. I don't like this convention because it adds noise that the human reader is going to mentally parse out anyway, so why not parse it out for him? Better to name the type Car_Type, and the instance Car, becuase the object is going to be refered to more often than the type itself. > Matthew, you seem to be advocating a variation on the "abbreviation" > approach: Come up with some wordy phrase for a type name, and then > arbitrarily lop off some part of that phrase to come up with a variable > name. That seems ad hoc to me. I wouldn't call it ad hoc. You don't come up with a "wordy" phrase for the type name _arbitrarily_. Just the opposite is true: you come up with an adjective that applies to your abstraction. A new member of the team I'm on declared a bunch of types (it was a binding to a tape drive API) all using the _T convention. I pointed out to him that perhaps a better name would be to include the tape drive in the type name, instead of using _T. His rebuttal was to ask me how I'd name a color type. My immediate response is, "Well, what is it a color of?" He said, "Say, a car." So my advice was, name the type Car_Color, not Color_Type. Nor is the object name ad hoc: simply remove the adjective part of the name, and keep the noun part. Just like Mode is an instance of type File_Mode, or File is an instance of File_Type, or Pool is an instance of Static_Storage_Pool. Another simple example: I like to name all scalar types with a dimension by using the units in the name, as in Speed : Speed_In_MPH; Length : Length_In_Meters; This solves the object-name type-name issue, and removes any ambiguity about what units apply to the scalar type. When refering to a literal, I like to use a qualified name, as in Set_Speed (Car, Speed => Speed_In_MPH'(10.0)); to let the reader know that I really knew I was doing, setting the speed to a value with units in miles per hour. (It would also help if you needed to change the units for some reason; the compiler would complain about a now non-existent type.) > If it was important enough to say, in a type name, that something is a > "Car_Steering_Wheel" (as opposed to, perhaps, a "Truck_Steering_Wheel"), > then why isn't it also important to say "Car_Steering_Wheel" in the > variable name too? Why arbitrarily lop off the "Car_" part? Because you only need to tell me once about the nature of the abstraction. We all know, by reading the _entire_ declaration (not just the object name), that we're talking about the steering wheel of a car. It _is_ important to tell my that this is a car steering wheel, but you only need to tell me once (at declaration time), not tell me again and again and again every time I refer to the object. Because then it would just become information the reader is going to mentally parse out. So when I see an object called Mode, I know that this is a File_Mode, because I read the subprogram from top to bottom, starting with the declarative region, and noticed the declaration of object Mode. Had I started reading in the middle of the subprogram, and see object Mode, I simply scan the program text backwards until I find the declaration. (And if I have too scan far back, then the subprogram is probably too long.) > On the other hand, if the "Car_" part is already understood (because the > type is already nested inside a "Cars" package), then why bother with > the "Car_" part in the first place, in the type name? Isn't that just > noise? The Car_ part is there because we need to have a different name for the type, because we want to call the object Steering_Wheel. To use _Type really would be noise, because that doesn't tell me anything I don't already know (even though it does satisfy the need to use a different identifier for the type). If we know that the object is going to be called Steering_Wheel, and that we need a different (and longer) name for the type, then you might as well add additional, substantive information about the abstraction the type describes. (Note that I'm proceeding here under that assumption that types don't just float around in space; they're there for a reason, and steering wheel abstractions "go with" car abstractions. As they say, "No object is an island.") > If the type name were only "Steering_Wheel", what would you propose > lopping off from that to make the variable name? The "Steering_" part? > Then why did we need to say "Steering_" in the type name? Isn't that > just noise too? Precisely why I wouldn't name the type just Steering_Wheel. Then the object name would be Wheel, and that name has too many other potential meanings. The object name Steering_Wheel is unambiguous. > On the other hand, what if the car doesn't just have a steering wheel, > but also has four drive wheels? Then don't we need to say > "Steering_Wheel" and "Drive_Wheel", not only in the type names but also > in the variable names too? What do we lop off where? You might decide on the convention that "Wheel" refers to drive wheels, and "Steering_Wheel" refers to steering wheels. Or, you could lengthen the type names. Name the type Drive_Wheel_Type if you don't care for Car_Drive_Wheel. > And what do you propose we lop off of the type name "Car" to make a > variable name? Alternatively, what "noise" word shall we tack onto the > type name so we can then lop it off? If we were manipulating a class-wide object, then the object name would be Car the type Root_Car, as in procedure Move (Car : in out Root_Car'Class); This class-wide operation ("template method" for readers of the GoF book) would dispatch primitive operations of types in the Root_Car class. > A naming convention should be systematic, mechanical, predictable and > transparent. That means that it should take NO THOUGHT to apply it, or > to interpret the results. Be careful not to assume that God decided that this is so. This description of a "good" naming convention is a choice YOU made. In fact, I take the exact opposite position, and think that type names require careful consideration of the application, the nature of the abstraction, and of the intended names of instances. Yes, this sometimes requires thinking (gasp!) and a certain amount of creativity. This is our real disagreement. Clearly, you and I are arguing using a different set of axioms. No substantive debate can occur unless all parties agree on first principles. > The argument that this limits a programmer's creativity is specious. I'm not suggested that mechanical application of a naming convention limits a programmer's creativity. In fact, the convention I advocate often can be applied mechanically. > But I am at a loss to see how Heaney style would meet these criteria > in the most general case. Please don't call this the Heaney style - call it the RM style. My argument isn't for a naming convention per se, it's that we should stick to the conventions already being used in the language reference manual. (But, like reading the Bible or the US Constitution, those conventions are sometimes subject to interpretation, and aren't guaranteed to work for anything but what's required to write a reference manual!) ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-09 0:00 ` Matthew Heaney @ 1998-08-10 0:00 ` John G. Volan 1998-08-11 0:00 ` John Volan ` (2 more replies) 0 siblings, 3 replies; 138+ messages in thread From: John G. Volan @ 1998-08-10 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > "John G. Volan" <johnvolan@sprintmail.com> writes: > > > (In fact, since P.D.'s example was Eiffel, the > > "STEERING_WHEEL" type would _be_ its own module). > > Your point highlights a difference between the two languages. In Ada, > it's very natural to declare related ("cohesive") types in a single > module. I was proceeding under the assumption that steering wheel type > didn't stand on its own; that it supported the larger car abstraction, > and hence was declared in the car module. > > This is a very common idiom in Ada, where you have a single module that > exports one or more primary ADTs, supplemented by auxiliary types that > describe attributes of the primary abstraction(s). Yes, this is an interesting idiom, and one may compare Ada's scheme of grouping cohesive types within Ada packages with Java's scheme of grouping cohesive classes within Java packages, or with Eiffel's scheme of grouping cohesive classes within clusters using the Lace language. However, this is off on a tangent from P. Doyle's question. P.D.'s question (and mine) was essentially this: You have a simple concept for some class of entities within your problem domain, and you have come up with a short, pithy noun phrase (e.g., "CAR", "STEERING_WHEEL") that names this concept within the context of your problem domain. Let us assume that the verbiage in this noun phrase is no more and no less than what is needed to convey the entire problem-domain concept you have in mind; in other words, the component words are at once necessary and sufficient. If that assumption is true, then removing any words would yield an abbreviation, which is insufficient; adding any words would create noise, which is unnecessary. Even words that convey the context of the problem domain are unnecessary, since such context can either be assumed, or expressed as module (package) names. All things being equal, this necessary-and-sufficient noun phrase is desirable both as an identifier for a type, and as an identifier for an (arbitrary) variable of that type. Every programming language requires some mechanism for distinguishing such identifiers from each other. Ada's mechanism is to force the identifiers to be literally different, which means either adding some kind of noise word to one or the other, or resorting to abbreviation for one or the other. Many react with distaste to either prospect, because they recognize both as catering to the programming language, and not to the problem domain concept we are trying to express. (Remember, the noun phrase in question is presumed to be both necessary and sufficient to express the concept.) Adding noise seems less obnoxious than abbreviation. So what's the least obnoxious noise you can add? > > So your answer begs the question: What, then, would you call an instance > > of the "CAR" type? > > > > In Eiffel, the answer is fairly simple: > > > > car : CAR ... > If it's the root of a tagged type hierarchy, then I would call it > Root_Car, just like they do in the RM (example: Root_Storage_Pool). I hope you recognize that "Root_" is as much a noise word as any other, because it caters to the mechanisms of the language rather than to the problem domain. Most OO programmers would find it distasteful to mark the class at the top of an inheritance hierarchy this way, simply because it was at the top of an inheritance hierarchy. But this is another tangent irrelevant to P.D.'s simple question, and it doesn't address the general case. What if, for the particular problem domain at hand, "CAR" is _not_ intended as the top of an inheritance hierarchy? In fact, what if we even wanted to _preclude_ any inheritance? (In Ada terms, the Car type would be non-tagged. In Java, it would be a final class. In Eiffel ... not sure of the syntax.) In that case, attaching the "Root_" prefix would not only be noise, it would be misleading noise. So the question remains: All things being equal, what's the least noxious noise you can add, that will work even in the most general case? > ... I think it's confusing to use > expanded name notation to differentiate between otherwise identical > names for object and type. Use different identifiers for each. On this point, I agree. > > It seems to me that if one is forced to come up with distinct > > identifiers for a type and an (arbitrary) instance of that type, then > > the difference between the identifiers should reflect this base/meta > > distinction. Thus, the Cohen style: > > > > Car : Car_Type; > > Sometimes, if there really is no suitable adjective to describe the type > (or, you're just not feeling too creative that day), then you do have to > use _Type as the type name. But I find those times to be rare. Again, I take exception to the notion that it is "uncreative" to be systematic. I'd rather focus my creativity on the terminology of the problem domain and not waste it on irrelevant artefacts of the coding process. But I find it interesting that you fall back to my position as a sort of default: When all else fails, use the base/meta (object/type) distinction as a source for the extra noise. But otherwise, be "creative": Derive the noise, if you can, from some aspect of your program design that's irrelevant to the problem domain (e.g. add "Root_" to "Car"); or in other cases, redundantly express context that might already be expressed in the module structure (e.g. add "Car_" to "Steering_Wheel", even though it's already nested in a "Cars" package). What other cases do you propose? With all these various cases, isn't your scheme really ad hoc? If you claim it is not ad hoc, can you articulate a finite number of rules that cover all situations (or at least a sufficient majority of them)? The fewer rules the better, because it means less effort for code writers to apply them, less effort for code readers to determine which rule has been applied in a particular situation, less effort for maintainers to keep straight what they're talking about when they converse about the code, etc. Personally, I find the form of "creativity" you advocate to be dubious. I know of no analog for your scheme in the idioms of any other programming language. Why not just settle on a simpler and more systematic way to introduce the required noise, and have done with it? The base/meta distinction is always there, in every case. In fact, it is the entire reason for this naming dilemma in the first place: We have objects, and we have their types, and Ada requires that they have different identifiers. So why not just have a single rule: Consistently mark every type as such, and reserve the unmarked noun phrase for a possible variable name. It's how people speak about the code anyway: "... and in this method we have an argument 'car' which is an instance of the 'car' type, which we're using to ..." > > The old Booch style: > > > > The_Car : Car; > > > > also reflects this same base/meta distinction. > > I don't like this convention because it adds noise that the human reader > is going to mentally parse out anyway, so why not parse it out for him? But the whole point is that every scheme introduces noise. We are only quibbling over which form of noise is the least distasteful. I could as easily say that the human reader is only interested that the thing is a "Car", and will just parse out the "Root_" part anyway; or that the thing is a "Steering_Wheel" from the "Cars" package, and will just parse out the "Car_" part anyway; so why not just parse out these noise words for him? > Better to name the type Car_Type, and the instance Car, becuase the > object is going to be refered to more often than the type itself. Yes, I agree that there is a strong argument in favor of putting the burden of marking upon the type identifier, in order to keep variable names as short as possible. However, when you add packages into this naming dilemma, it seems as if a Booch-like style is still somewhat compelling, as J-P Rosen's style suggests: The_Car : Car.Instance; The_Steering_Wheel : Steering_Wheel.Instance; Booch style gives the unmarked noun to the type; Rosen style gives it instead to the package, and the encapsulated type gets a systematic noise word. It would have been nice if this word could have been just "Type": The_Car : Car.Type; The_Steering_Wheel : Steering_Wheel.Type; but of course "type" is a reserved word. (I once toyed with "Tipe", but thought better of it ... :-) > A new member of the team I'm on declared a bunch of types (it was a > binding to a tape drive API) all using the _T convention. I pointed out > to him that perhaps a better name would be to include the tape drive in > the type name, instead of using _T. > > His rebuttal was to ask me how I'd name a color type. My immediate > response is, "Well, what is it a color of?" He said, "Say, a car." So > my advice was, name the type Car_Color, not Color_Type. But you see, you diverted the poor guy off onto a tangent. What if he had responded, "Why, it's a color of anything that can _be_ colored, not just the color of a car. In short, "Color" is an abstraction all its own, in a module of its own that is all about colors. Please don't pollute that abstraction by making it specific to just one particular usage... Now, this abstraction is about "Color" and only about "Color". I want to call the package "Color". But I also want to call the encapsulated type "Color". And I want to call the controlling parameter "Color" in each of my primitve operations, too. How do I resolve this dilemma?" > Nor is the object name ad hoc: simply remove the adjective part of the > name, and keep the noun part. Just like Mode is an instance of type > File_Mode, I don't think the original designers of Text_IO necessarily completely thought through all the issues of naming conventions back then. Isn't the "File_" part in "File_Mode" just a redundant re-iteration of the context, since we know that Text_IO is all about text files anyway? (I sometimes wish Text_IO had been named Text_Files instead, as this would have been a more "object-oriented" name; "Text Input/Output" is the _function_ this package supports, but "Text Files" are the _objects_ this package is _about_.) On the other hand, let's suppose "File_Mode" is a necessary and sufficient phrase to express the whole sense of the concept (presumably within a use-ophilic environment). Maybe you can get away with dropping the "File_" adjective for a variable within the package, but can you always do that outside the package, in all its conceivable clients? What if there's a context where you have both a "File_Mode" and some other kind of mode, say an "Operational_Mode" (e.g., Real vs. Simulated)? Then it becomes important to use the complete names for those concepts, including the "File_" and "Operational_" prefixes, not just in their type names but also in the variable names. If we now need "File_Mode" and "Operational_Mode" as variable names, what should the types have been called? You know, I'm not averse to the idea, per se, of dropping prefixed adjectives when they can be understood from the context. In fact, in object-oriented software, it's often the case that a subclass name will be formed by prefixing an appropriate adjective onto its superclass name. A variable of the subclass type can just as easily be thought of as a variable of the superclass type, so it can be legitimate to just refer to the variable using the simpler terminology of the superclass type. I'm just against the idea that dropping prefixed adjectives offers a general solution to the object/type name dilemma. One can always come up with cases where you need to put those adjectives back in, or where there are no appropriate adjectives to drop in the first place. > Another simple example: I like to name all scalar types with a dimension > by using the units in the name, as in > > Speed : Speed_In_MPH; > Length : Length_In_Meters; > > This solves the object-name type-name issue, and removes any ambiguity > about what units apply to the scalar type. As I've pointed out in the past, if it's important to say something in a type name, there could easily be a case where it's important to say it in the variable name too: Speed_In_MPH : Speed_In_MPH_Type; Speed_In_Knots : Speed_In_Knots_Type; ... Speed_In_Knots := To_Knots(Speed_In_MPH); > When refering to a literal, > I like to use a qualified name, as in > > Set_Speed (Car, Speed => Speed_In_MPH'(10.0)); How about just: Set_Speed (Car, Speed_In_MPH => 10.0); Or perhaps we should consider the word "Speed" to be unnecessary noise: MPH : MPH_Type; Knots : Knots_Type; ... Knots := To_Knots(MPH); ... Set_Speed (Car, MPH => 10.0); Perhaps "Speed" could be the name of the package that houses the MPH_Type and Knots_Type, and the To_Knots function, etc... > > If it was important enough to say, in a type name, that something is a > > "Car_Steering_Wheel" (as opposed to, perhaps, a "Truck_Steering_Wheel"), > > then why isn't it also important to say "Car_Steering_Wheel" in the > > variable name too? Why arbitrarily lop off the "Car_" part? > > Because you only need to tell me once about the nature of the > abstraction. We all know, by reading the _entire_ declaration (not just > the object name), that we're talking about the steering wheel of a car. > It _is_ important to tell my that this is a car steering wheel, but you > only need to tell me once (at declaration time), not tell me again and > again and again every time I refer to the object. Because then it would > just become information the reader is going to mentally parse out. Unless there's a situation where it becomes important again to distinguish it as a car's steering wheel, and we find we need to put that adjective back: Car_Steering_Wheel : Car_Steering_Wheel_Type := ... Tow_Truck_Steering_Wheel : Tow_Truck_Steering_Wheel_Type := ... ... -- make the Car simulation physically follow the Tow_Truck simulation: Set_Direction (Car_Steering_Wheel, Get_Direction (Tow_Truck_Steering_Wheel)); > > On the other hand, if the "Car_" part is already understood (because the > > type is already nested inside a "Cars" package), then why bother with > > the "Car_" part in the first place, in the type name? Isn't that just > > noise? > > The Car_ part is there because we need to have a different name for the > type, because we want to call the object Steering_Wheel. So basically you're saying the "Car_" part is just noise, right? > To use _Type really would be noise, because that doesn't tell me > anything I don't already know (even though it does satisfy the need to > use a different identifier for the type). But "Car_" doesn't tell me something I don't already know, either, right? I mean, to understand the entire abstraction, we don't just look at a single _declaration_, we look at the whole _package_ that encapsulates it, right? The package name "Cars" already says it all. > If we know that the object is going to be called Steering_Wheel, and > that we need a different (and longer) name for the type, then you might > as well add additional, substantive information about the abstraction > the type describes. But what substantive information are you adding that hasn't already been supplied in other ways? with Cars; -- assume this is written by a use-o-phobe ... My_Cars_Steering_Wheel : Cars.Car_Steering_Wheel; ^^^^^^^^ Isn't this redundant, and therefore noise? > (Note that I'm proceeding here under that assumption that types don't > just float around in space; they're there for a reason, and steering > wheel abstractions "go with" car abstractions. As they say, "No object > is an island.") Some objects are indeed islands, if we choose to keep them uncoupled to other objects. Making abstractions "go with" each other in a single package increases coupling. That's a design choice. The benefits of cohesion sometimes outweigh the cost of the coupling, but nevertheless the coupling does incur a cost. Sometimes the cost of coupling is too dire, so the right design choice is to separate things out. > > A naming convention should be systematic, mechanical, predictable and > > transparent. That means that it should take NO THOUGHT to apply it, or > > to interpret the results. > > Be careful not to assume that God decided that this is so. This > description of a "good" naming convention is a choice YOU made. > > In fact, I take the exact opposite position, and think that type names > require careful consideration of the application, the nature of the > abstraction, and of the intended names of instances. How is this the "opposite" of what I have been saying? Of course you should take great care in choosing names that express the problem domain _concepts_ you wish to address in your program. There is a great deal of care, consideration, and indeed creativity that goes into this design process. But once you have found names for your concepts, rendering those concepts into types and variables should be as direct and straightforward as possible. If your programming language forces you to spend additional creative energy just to cater to its syntactic foibles, that's a waste. It would be as much of a waste to spend time deciding what noise word to add, just for the sake of differentiating a type name from variable name, as it is to spend time figuring out that: if (x = y) ... really should have been: if (x == y) ... > I'm not suggested that mechanical application of a naming convention > limits a programmer's creativity. In fact, the convention I advocate > often can be applied mechanically. You seem to be contradicting yourself. How can your convention be applied mechanically if by definition it requires creativity? If your convention can be expressed as a finite set of rules that cover all situations, then by definition it would require no creativity (beyond the initial creativity needed to give names to problem domain concepts, of course). > Please don't call this the Heaney style - call it the RM style. My > argument isn't for a naming convention per se, it's that we should stick > to the conventions already being used in the language reference manual. There appear to be many different conventions demonstrated within the RM, possibly as many different styles as there were designers on the design teams. Perhaps the RM can be viewed as a forum where precedents for various styles were recorded, but I don't think the intent of the RM was ever to establish some particular coding style as the ideal. Its primary intent, after all, was to unambiguously specify what the language is, not to prescribe how it should be used. Precedent, even long precedent, should not be the only criterion for chosing a coding style. I would think it's more important to base the choice on a well-thought out rationale. As much as we venerate the wise men of ancient days, they really were no closer to God than we are now. But we have had more time to think about it than they did. -- Signature volanSignature = new Signature ( /*name: */ "John G. Volan", /*employer: */ "Raytheon/TI 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, named parameter passing, etc...", /*disclaimer:*/ "These views not packaged in COM.ti.dseg.ac3i.*, " + "so loading them throws DontQuoteMeError. :-) " ); ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-10 0:00 ` John G. Volan @ 1998-08-11 0:00 ` John Volan 1998-08-11 0:00 ` Don Harrison 1998-08-31 0:00 ` Matthew Heaney 2 siblings, 0 replies; 138+ messages in thread From: John Volan @ 1998-08-11 0:00 UTC (permalink / raw) John G. Volan wrote: > > In fact, what if we even wanted to _preclude_ any > inheritance? (In Ada terms, the Car type would be non-tagged... On second thought, making a type non-tagged doesn't actually preclude _inheritance_ as such. In Ada, one may derive a new type from any type, even from a scalar type such as Integer; the new type technically inherits all the properties of the parent type, including all its primitive operations (those declared in the same package spec with the parent type). In this sense, even Ada83 supported inheritance. What a non-tagged type does preclude is type extension, polymorphic class-wide programming, and dynamic dispatching. But to my knowledge, there is no mechanism in Ada to selectively prevent type _derivation_. -- 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] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-10 0:00 ` John G. Volan 1998-08-11 0:00 ` John Volan @ 1998-08-11 0:00 ` Don Harrison 1998-08-11 0:00 ` geoff 1998-08-31 0:00 ` Matthew Heaney 2 siblings, 1 reply; 138+ messages in thread From: Don Harrison @ 1998-08-11 0:00 UTC (permalink / raw) John G. Volan wrote: :In fact, what if we even wanted to _preclude_ any :inheritance? (In Ada terms, the Car type would be non-tagged. In Java, :it would be a final class. In Eiffel ... not sure of the syntax.) frozen do_something (..) is .. ^^^^^^ Don. Don Harrison donh at syd.csa.com.au ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-11 0:00 ` Don Harrison @ 1998-08-11 0:00 ` geoff 0 siblings, 0 replies; 138+ messages in thread From: geoff @ 1998-08-11 0:00 UTC (permalink / raw) In article <ExIqpp.36J@syd.csa.com.au>, nospam@thanks.com.au wrote: > John G. Volan wrote: > > :In fact, what if we even wanted to _preclude_ any > :inheritance? (In Ada terms, the Car type would be non-tagged. In Java, > :it would be a final class. In Eiffel ... not sure of the syntax.) > > frozen do_something (..) is .. > ^^^^^^ Don's Eiffel syntax is correct. Check out Eric Bezault's annotated ``Eiffel: The Syntax'' web page at: http://www.gobo.demon.co.uk/eiffel/syntax/ Just search for ``frozen'' - it appears in ``New_feature'' aggregate. > Don. > Don Harrison donh at syd.csa.com.au Hope this helps .. Geoff Eldridge -- ``Eiffel, Back to the Future'' -- geoff@elj.com -- elj-win32: http://www.elj.com/elj-win32/ -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-10 0:00 ` John G. Volan 1998-08-11 0:00 ` John Volan 1998-08-11 0:00 ` Don Harrison @ 1998-08-31 0:00 ` Matthew Heaney 1998-08-31 0:00 ` Tucker Taft ` (5 more replies) 2 siblings, 6 replies; 138+ messages in thread From: Matthew Heaney @ 1998-08-31 0:00 UTC (permalink / raw) "John G. Volan" <johnvolan@sprintmail.com> writes: > Ada's mechanism is to force the identifiers to be literally different, > which means either adding some kind of noise word to one or the other, > or resorting to abbreviation for one or the other. Many react with > distaste to either prospect, because they recognize both as catering > to the programming language, and not to the problem domain concept we > are trying to express. (Remember, the noun phrase in question is > presumed to be both necessary and sufficient to express the concept.) > Adding noise seems less obnoxious than abbreviation. So what's the > least obnoxious noise you can add? I do this sort of thing too: PDW : Pulse_Descriptor_Word; SOI : Signal_Of_Interest; Speed : Speed_In_Knots; > I hope you recognize that "Root_" is as much a noise word as any > other, because it caters to the mechanisms of the language rather than > to the problem domain. Most OO programmers would find it distasteful > to mark the class at the top of an inheritance hierarchy this way, > simply because it was at the top of an inheritance hierarchy. I'm not sure I understand the argument that you have to "cater to the language mechanisms." Under what circumstances do you not have to cater to the language mechanisms? Isn't this what this whole thread is about, how to program in Ada? We have to cater to the language mechanisms wrt naming of types (wrt to anything, actually), so what's the best way to do that? > But this is another tangent irrelevant to P.D.'s simple question, and > it doesn't address the general case. What if, for the particular > problem domain at hand, "CAR" is _not_ intended as the top of an > inheritance hierarchy? In fact, what if we even wanted to _preclude_ > any inheritance? (In Ada terms, the Car type would be non-tagged. In > Java, it would be a final class. In Eiffel ... not sure of the > syntax.) In that case, attaching the "Root_" prefix would not only be > noise, it would be misleading noise. I would only use "Root_" as a prefix for the root type in a hierarchy of tagged types. Under no circumstances would I name a non-tagged type "Root_". > So the question remains: All things being equal, what's the least > noxious noise you can add, that will work even in the most general > case? Again, we have different philosophies here. You argue for a simple solution ("_Type", I think) that can be applied mechanically, all the time. That's fine. However, I'm trying my best only use _Type as an indicator of static polymorphism, and so am advocating a slighly more complicated convention. Note that this doesn't preclude mechanical application. > With all these various cases, isn't your scheme really ad hoc? I wouldn't describe what I do as ad hoc. If you've read the code in my other posts, I'm sure you wouldn't describe it as ad hoc either. You might even be tempted to say it's sorta elegent. > If you claim it is not ad hoc, can you articulate a finite number of > rules that cover all situations (or at least a sufficient majority of > them)? Hmmm. Let's see. 1) Name the (abstract) root of a hierarchy of tagged types Root_. One exception (oops, an exception already, on the first bullet!) is if there's already a good two-part name from the problem domain, use that instead of Root_. The classic example is Bank_Account, from which Checking_Account and Savings_Account derive. 2) Name the type _Type to indicate static polymorphism, ie generic ... package Stacks_Unbounded is type Stack_Type is private; generic ... package Stacks_Bounded is type Stack_Type is private; 3) Name scalar types using the units in the name, ie type Heading_In_Degrees is ...; 4) If you often refer to an acronym, then use expanded name as the type, SOI : Signal_Of_Interest; PDW : Pulse_Descriptor_Word; 5) Name arrays _Array, and name the array instance the plural: type Stack_Item_Array is array (Positive range <>) of Stack_Item; Items : Stack_Item_Array; 6) Never ever name a scalar type as a plural type Tuner_Ids is range 1 .. 4; -- you're a bad boy I makes zero sense to see this Id : Tuner_Ids; since we're only talking about a single object, not an array or set. So stick to the singular convention type Tuner_Id is range 1 .. 4; Id : Tuner_Id; 7) Use an adjective-noun phrase to name the type: Tuner_Id Character_Glyph Bounded_String File_Mode > Why not just settle on a simpler and more systematic way to introduce > the required noise, and have done with it? If you use _Type everywhere, it just becomes noise. If I have to use an extra word (I do), then I prefer that the word carry some useful information. > So why not just have a single rule: Consistently mark every type as > such, and reserve the unmarked noun phrase for a possible variable > name. See above. > But the whole point is that every scheme introduces noise. We are only > quibbling over which form of noise is the least distasteful. No. The extra verbiage doesn't have to become noise - it can tell me something useful (like the units). > I could as easily say that the human reader is only interested that > the thing is a "Car", and will just parse out the "Root_" part anyway; > or that the thing is a "Steering_Wheel" from the "Cars" package, and > will just parse out the "Car_" part anyway; so why not just parse out > these noise words for him? Because I wouldn't say that "Car_" is a noise word. > But you see, you diverted the poor guy off onto a tangent. What if he > had responded, "Why, it's a color of anything that can _be_ colored, > not just the color of a car. In short, "Color" is an abstraction all > its own, in a module of its own that is all about colors. No. I was talking specifically about the color attribute of a car abstraction. You have no guarantee that a car abstraction can have all possible values for color. Hence, Car_Color. > I don't think the original designers of Text_IO necessarily completely > thought through all the issues of naming conventions back then. Isn't > the "File_" part in "File_Mode" just a redundant re-iteration of the > context, since we know that Text_IO is all about text files anyway? > (I sometimes wish Text_IO had been named Text_Files instead, as this > would have been a more "object-oriented" name; "Text Input/Output" is > the _function_ this package supports, but "Text Files" are the > _objects_ this package is _about_.) Look at Text_IO as a machine (which it is). It does more that just export an ADT - it manages state too (Standard_Input, Standard_Output). The name Text_Files would be misleading, because Text_IO is not an ADT package - it's a singleton abstraction that happens to export an ADT. > On the other hand, let's suppose "File_Mode" is a necessary and > sufficient phrase to express the whole sense of the concept > (presumably within a use-ophilic environment). Maybe you can get away > with dropping the "File_" adjective for a variable within the package, > but can you always do that outside the package, in all its conceivable > clients? What if there's a context where you have both a "File_Mode" > and some other kind of mode, say an "Operational_Mode" (e.g., Real vs. > Simulated)? Then it becomes important to use the complete names for > those concepts, including the "File_" and "Operational_" prefixes, not > just in their type names but also in the variable names. If we now > need "File_Mode" and "Operational_Mode" as variable names, what should > the types have been called? That does happen sometimes, especially subprogram parameters. I would probably do something like this: procedure Op (File : in out File_Type; FMode : in File_Mode; OMode : in Operation_Mode); > You know, I'm not averse to the idea, per se, of dropping prefixed > adjectives when they can be understood from the context. I argue that you have to read the entire declaration to get all the information. Sometimes I see guys to this: procedure Op (... The_File_Mode : in File_Mode; ...); but it all seems very redundent. By reading the entire declaration, including the type name, that I get all the information I need, but more concisely, as in procedure Op (... Mode : in File_Mode; ...); > As I've pointed out in the past, if it's important to say something in > a type name, there could easily be a case where it's important to say > it in the variable name too: > > Speed_In_MPH : Speed_In_MPH_Type; > Speed_In_Knots : Speed_In_Knots_Type; > ... > Speed_In_Knots := To_Knots(Speed_In_MPH); See my point above. The times when I care about the specific units of speed are only a subset of all the times I manipulate a speed. When I really do care about the units, I just navigate to the declaration, the read units from the type name. You don't need to tell me the units every single time, because I don't care about units every single time. And when I don't care, I have to mentally parse it out. > > When refering to a literal, > > I like to use a qualified name, as in > > > > Set_Speed (Car, Speed => Speed_In_MPH'(10.0)); > > How about just: > > Set_Speed (Car, Speed_In_MPH => 10.0); Then you've made the choice for the client. I prefer that the client be able to decide how much verbosity he wants to include at the point of call. > Or perhaps we should consider the word "Speed" to be unnecessary noise: > > MPH : MPH_Type; > Knots : Knots_Type; > ... > Knots := To_Knots(MPH); > ... > Set_Speed (Car, MPH => 10.0); > > Perhaps "Speed" could be the name of the package that houses the > MPH_Type and Knots_Type, and the To_Knots function, etc... I don't like this idea. The characteristics of the supporting type, such as whether it's fixed or float, the digits of precision, range, etc, are determined by the larger abstraction. So I usually place the attribute types there, with the abstraction they describe. > Unless there's a situation where it becomes important again to > distinguish it as a car's steering wheel, and we find we need to put > that adjective back: > > Car_Steering_Wheel : Car_Steering_Wheel_Type := ... > Tow_Truck_Steering_Wheel : Tow_Truck_Steering_Wheel_Type := ... > ... > -- make the Car simulation physically > -- follow the Tow_Truck simulation: > Set_Direction (Car_Steering_Wheel, Get_Direction (Tow_Truck_Steering_Wheel)); Well, I alluded to another technique, and that's to go ahead an use an abbreviation, as in CWheel : Car_Steering_Wheel; TWheel : Truck_Steering_Wheel; for those few times when you have two wheel objects in the same scope. > > The Car_ part is there because we need to have a different name for the > > type, because we want to call the object Steering_Wheel. > > So basically you're saying the "Car_" part is just noise, right? No. "Car" is never noise. "Car" is signal. > But "Car_" doesn't tell me something I don't already know, either, > right? I mean, to understand the entire abstraction, we don't just > look at a single _declaration_, we look at the whole _package_ that > encapsulates it, right? The package name "Cars" already says it all. I'm a use-o-phile. Therefore I'm not looking at the Cars package when I'm reading the declaration of an object (because I didn't use an expanded name). So the Car_ is telling me something. > > If we know that the object is going to be called Steering_Wheel, and > > that we need a different (and longer) name for the type, then you might > > as well add additional, substantive information about the abstraction > > the type describes. > > But what substantive information are you adding that hasn't already > been supplied in other ways? > > with Cars; -- assume this is written by a use-o-phobe > ... > My_Cars_Steering_Wheel : Cars.Car_Steering_Wheel; > ^^^^^^^^ > > Isn't this redundant, and therefore noise? I agree - there is redundancy. We can resolve that in two ways: 1) use a use, and ditch the expanded name; or 2) don't use a use, and ditch the Car_ prefix. I choose option 1). > Some objects are indeed islands, if we choose to keep them uncoupled > to other objects. Making abstractions "go with" each other in a > single package increases coupling. That's a design choice. Well, yes and no. I argue that the color of a car is determined by the characteristics of the car abstraction, so the declaration of (car) color goes with the declaration of car. For example, the factory that manufactures the cars will only produce a limited number of possible colors, and the abstraction should capture that feature of the domain. > Its [the RM] primary intent, after all, was to unambiguously specify > what the language is, not to prescribe how it should be used. Well, that's a bit of a stretch. I'd say just the opposite is true. > Precedent, even long precedent, should not be the only criterion for > chosing a coding style. I would think it's more important to base the > choice on a well-thought out rationale. Agreed. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-31 0:00 ` Matthew Heaney @ 1998-08-31 0:00 ` Tucker Taft 1998-09-06 0:00 ` John G. Volan 1998-09-04 0:00 ` John G. Volan ` (4 subsequent siblings) 5 siblings, 1 reply; 138+ messages in thread From: Tucker Taft @ 1998-08-31 0:00 UTC (permalink / raw) Matthew Heaney (matthew_heaney@acm.org) wrote: : "John G. Volan" <johnvolan@sprintmail.com> writes: : > Ada's mechanism is to force the identifiers to be literally different, : > which means either adding some kind of noise word to one or the other, : > or resorting to abbreviation for one or the other. : > ... : I do this sort of thing too: : PDW : Pulse_Descriptor_Word; : : SOI : Signal_Of_Interest; : Speed : Speed_In_Knots; A better choice for object names is often something that indicates the specific role the object plays, rather than a name that simply echos its type name. Presumably there is more than one object of a given type in existence. The names ought to distinguish these objects by hinting to the reader what they are used for. For example, an object of type "Speed_In_Knots" is presumably the speed for some particular other entity. Presuming that that other entity has a meaningful name, then its speed might be named "<entity>_Speed". Prepositions like "From" or "To", qualifiers like "Source" and "Target" or "Next" and "Prev", etc., often are better than just names that parrot the type. Remember that every name is a chance to communicate something of interest to the reader. Make every name count (sounds like bidding in the game of "Bridge" -- "make every bid count"). -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-31 0:00 ` Tucker Taft @ 1998-09-06 0:00 ` John G. Volan 1998-09-06 0:00 ` Matthew Heaney 0 siblings, 1 reply; 138+ messages in thread From: John G. Volan @ 1998-09-06 0:00 UTC (permalink / raw) Tucker Taft wrote: > > A better choice for object names is often something that indicates > the specific role the object plays, rather than a name that simply echos > its type name. ... > Prepositions like "From" or "To", qualifiers like "Source" and "Target" > or "Next" and "Prev", etc., often are better than just names that > parrot the type. > > Remember that every name is a chance to communicate something of > interest to the reader. Make every name count (sounds like bidding > in the game of "Bridge" -- "make every bid count"). Yes, role names (particularly role names on logical associations a la UML) are a fertile source of variable names (especially names for object attributes -- record components, in Ada terms). When an analysis of the problem domain provides such names, they should of course be used to advantage. Borrowing an Eiffel example from OOSC2 (Meyer): class PERSON feature ... spouse: PERSON landlord: PERSON ... end and adapting it to Ada: type Person_Type is ... tagged ... private; type Person_Access_Type is access all Person_Type'Class; ... type Person_Type is ... tagged record ... Spouse : Person_Access_Type; Landlord : Person_Access_Type; ... end record; we can see that, in this case, the attribute names do not need to "parrot" the type name. However, many times the most appropriate role name turns out to be exactly the same term used for the type name itself, and so the type/object name-clash reasserts itself. For instance, going back to our (now quite moldy) example of the "color" of a "car", here in Eiffel: class CAR feature ... color: COLOR ... end ... -- Usage: car: CAR ... car.color ... and here in Ada: type Car_Type is ... record Color : Color_Type; end record; ... -- Usage: Car : Car_Type; ... Car.Color ... The attribute in this case is an instance of the "color" type. It plays the role of being the "color" of a "car". Calling it anything else ("paintjob"?) :-) would seem contrived. > Presumably there is more than one object of a given > type in existence. In "existence", perhaps, but not necessarily in a given scope ... > The names ought to distinguish these objects by > hinting to the reader what they are used for. This is true when these objects are in a scope where their distinguishing roles need to be highlighted. But in building the abstractions for our types, we often encounter objects in contexts where any specific role has been abstracted away: package Persons is type Person_Type is ... function Get_Name (Person : in Person_Type) return String; ... end Persons; What other "role" is the person in the Get_Name function playing, other than simply being the person whose name we wish to retrieve? Yes, we know that some actual parameters passed into this formal parameter may turn out to play specific roles such as "spouse" or "landlord" or "employee", but that is irrelevant at this level of abstraction. > For example, > an object of type "Speed_In_Knots" is presumably the speed for > some particular other entity. Presuming that that other entity has > a meaningful name, then its speed might be named "<entity>_Speed". Are you suggesting this sort of redundancy: type Car is ... record ... Car_Color : Color; Car_Speed : Speed_In_Knots; ... end record; ... -- Usage: Some_Car : Car; ... Some_Car.Car_Color ... ... Some_Car.Car_Speed ... ^^^^^^^ -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-06 0:00 ` John G. Volan @ 1998-09-06 0:00 ` Matthew Heaney 0 siblings, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-09-06 0:00 UTC (permalink / raw) "John G. Volan" <johnvolan@sprintmail.com> writes: > > For example, > > an object of type "Speed_In_Knots" is presumably the speed for > > some particular other entity. Presuming that that other entity has > > a meaningful name, then its speed might be named "<entity>_Speed". > > Are you suggesting this sort of redundancy: > > type Car is ... > record > ... > Car_Color : Color; > Car_Speed : Speed_In_Knots; > ... > end record; > > ... -- Usage: > Some_Car : Car; > ... Some_Car.Car_Color ... > ... Some_Car.Car_Speed ... Your example illustrates why it's probably better to name scalar types with both qualifier and units: type Car_Color is ...; type Car_Speed_In_MPH is ...; type Car_Type is record Speed : Car_Speed_In_MPH; Color : Car_Color; ... end record; Car : Car_Type; ... Car.Speed ... ... Car.Color ... ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-31 0:00 ` Matthew Heaney 1998-08-31 0:00 ` Tucker Taft @ 1998-09-04 0:00 ` John G. Volan 1998-09-06 0:00 ` Matthew Heaney 1998-09-04 0:00 ` John G. Volan ` (3 subsequent siblings) 5 siblings, 1 reply; 138+ messages in thread From: John G. Volan @ 1998-09-04 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > "John G. Volan" <johnvolan@sprintmail.com> writes: > > > But you see, you diverted the poor guy off onto a tangent. What if he > > had responded, "Why, it's a color of anything that can _be_ colored, > > not just the color of a car. In short, "Color" is an abstraction all > > its own, in a module of its own that is all about colors. > > No. I was talking specifically about the color attribute of a car > abstraction. You have no guarantee that a car abstraction can have all > possible values for color. Hence, Car_Color. Look, I provided you with one puzzle to solve, but you insist on solving a different one, one that's easier for you to fit into your scheme. Okay, fine, but how about solving my puzzle, too? What if -- what if -- you were presented with a problem domain where there are cars, and there are colors, and there are other things that can have colors, and any car can get any of the colors? For me, if I were coding in Ada, it would be simple: with Percentages; use Percentages; package Colors is type Color_Type is ... private; ... function Make_Color (Red_Percentage : Percentage_Type; Green_Percentage : Percentage_Type; Blue_Percentage : Percentage_Type) return Color_Type; ... Red : constant Color_Type; Green : constant Color_Type; Blue : constant Color_Type; White : constant Color_Type; Black : constant Color_Type; ... end Colors; with Colors; use Colors; ... package Cars is type Car_Type is ... private; ... function Get_Color (Car : in Car_Type) return Color_Type; procedure Paint (Car : in out Car_Type; Color : in Color_Type); ... private type Car_Type is ... record ... Color : Color_Type; ... end record; end Cars; package body Cars is ... function Get_Color (Car : in Car_Type) return Color_Type is begin return Car.Color; end Get_Color; procedure Paint (Car : in out Car_Type; Color : in Color_Type) is begin ... Car.Color := Color; ... end Paint; ... end Cars; -- Usage: with Cars; use Cars; with Colors; use Colors; ... Car : Car_Type; ... Paint (Car, Color => Blue); ... In Java, it would be even simpler: public class Color { public Color(Percentage redPercentage, Percentage greenPercentage, Percentage bluePercentage) { ... } public static final Color RED = ... ; public static final Color GREEN = ... ; public static final Color BLUE = ... ; public static final Color WHITE = ... ; public static final Color BLACK = ... ; ... } public class Car { private Color color; public Color getColor() { return color; } public void paint (Color newColor) { ... color = newColor; ... } ... } // Usage: ... Car car = new Car(...); ... car.paint(Color.BLUE); ... And in Eiffel it would also be simpler: expanded class COLOR creation make feature {NONE} make (redPercentage: PERCENTAGE; greenPercentage: PERCENTAGE; bluePercentage: PERCENTAGE) is do ... end ... end -- class COLOR class COLOR_CONSTANTS feature ... Red: COLOR is once ... end Green: COLOR is once ... end Blue: COLOR is once ... end White: COLOR is once ... end Black: COLOR is once ... end ... end -- class COLOR_CONSTANTS class CAR creation make feature ... color: COLOR -- note: no need for a get_color function, clients -- already see attributes as functions (read-only) -- due to principle of Uniform Access paint (new_color: COLOR) is do ... color := new_color ... end ... feature {NONE} make (...) is do ... end end -- class CAR -- Usage: ... inherit COLOR_CONSTANTS ... car: CAR; ... !!car.make(...) ... car.paint(Blue) ... Now, Matt, given the above, would you still insist that there had to be a "Car_Color" type somewhere? -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-04 0:00 ` John G. Volan @ 1998-09-06 0:00 ` Matthew Heaney 1998-09-06 0:00 ` John G. Volan 1998-09-06 0:00 ` John G. Volan 0 siblings, 2 replies; 138+ messages in thread From: Matthew Heaney @ 1998-09-06 0:00 UTC (permalink / raw) "John G. Volan" <johnvolan@sprintmail.com> writes: > Look, I provided you with one puzzle to solve, but you insist on solving > a different one, one that's easier for you to fit into your scheme. > Okay, fine, but how about solving my puzzle, too? What if -- what if > -- you were presented with a problem domain where there are cars, and > there are colors, and there are other things that can have colors, and > any car can get any of the colors? For me, if I were coding in Ada, it > would be simple: I don't accept your argument, because I don't accept your premise. I can only speak from my own experience. And from my own experience, color types, and speed types, and heading types, don't exist independently of higher level abstractions, like cars, and targets, and airframes, and ownships, etc. If you have a compelling need to declare an enumerated color type (say), for use by multiple abstractions, then go ahead and name it Color_Type: package Color_Types is type Color_Type is (...); end Color_Types; My philosophy is to use the name _Type only as a last resort, as it has a sort of generic quality to it. That sometimes turns out to be useful, as in the example above. Some guys name generic formal types _Type, for exactly that reason. But if I'm implementing a car abstraction that had a color attribute, then I would name the color type Car_Color. You point out a problem with this scheme, and that is if there are two color objects in the same scope. You correctly observed that my use of an abbreviation in that case wouldn't be necessary if I had used the name _Type. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-06 0:00 ` Matthew Heaney @ 1998-09-06 0:00 ` John G. Volan 1998-09-06 0:00 ` Brian Rogoff 1998-09-06 0:00 ` John G. Volan 1 sibling, 1 reply; 138+ messages in thread From: John G. Volan @ 1998-09-06 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > My philosophy is to use the name _Type only as a last resort, as it has > a sort of generic quality to it. Funny, I'd say its precisely this quality that should make _Type the *first* resort! :-) It's so generally applicable as a type-marking suffix one might as well use it everywhere... > That sometimes turns out to be useful, > as in the example above. Some guys name generic formal types _Type, for > exactly that reason. I'd say, don't treat generic formal types any differently than normal types: Mark 'em all with "_Type"! One nice feature of Cohen style is that it results in a clearly-readable distinction between generic formal parameter passing and subprogram parameter passing, which otherwise are syntactically identical (in Ada): -- Generic formal parameter passing: package Doctor_Lists is new Lists (Item_Type => Doctors.Doctor_Type); -- it's clear that the parameter -- being passed is a _type_ ... Doctor_List : Doctors_Lists.List_Type; Doctor : Doctors.Doctor_Type; ... Doctor_Lists.Append (List => Doctor_List, Item => Doctor); -- it's clear that the parameters -- being passed are _objects_ -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-06 0:00 ` John G. Volan @ 1998-09-06 0:00 ` Brian Rogoff 1998-09-06 0:00 ` John G. Volan 0 siblings, 1 reply; 138+ messages in thread From: Brian Rogoff @ 1998-09-06 0:00 UTC (permalink / raw) On Sun, 6 Sep 1998, John G. Volan wrote: > Matthew Heaney wrote: > > > > My philosophy is to use the name _Type only as a last resort, as it has > > a sort of generic quality to it. > > Funny, I'd say its precisely this quality that should make _Type the > *first* resort! :-) It's so generally applicable as a type-marking > suffix one might as well use it everywhere... Exactly my line of thinking too :-|. This is one of the reason's I like the Dylan convention of delimiting type names with angle brackets; this convention has the pleasing (to me) effect of making type names look very different from other lexical items. -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-06 0:00 ` Brian Rogoff @ 1998-09-06 0:00 ` John G. Volan 1998-09-07 0:00 ` Brian Rogoff 0 siblings, 1 reply; 138+ messages in thread From: John G. Volan @ 1998-09-06 0:00 UTC (permalink / raw) Brian Rogoff wrote: > > On Sun, 6 Sep 1998, John G. Volan wrote: > > Matthew Heaney wrote: > > > > > > My philosophy is to use the name _Type only as a last resort, as it has > > > a sort of generic quality to it. > > > > Funny, I'd say its precisely this quality that should make _Type the > > *first* resort! :-) It's so generally applicable as a type-marking > > suffix one might as well use it everywhere... > > Exactly my line of thinking too :-|. This is one of the reason's I like > the Dylan convention of delimiting type names with angle brackets; this > convention has the pleasing (to me) effect of making type names look very > different from other lexical items. I assume this makes it possible to do something like: Car : <Car>; Color : <Color>; In other words, the Dylan convention yields what are effectively two completely disjoint namespaces for object names and type names. The marking clearly indicates which namespace a given identifier belongs to. But except for the marking, identifiers in the two namespaces could be identical. Compare that with the style convention in Eiffel, where all-uppercase is used for type names and all-lowercase (or mixed case) is used for entity names. e.g. car : CAR color : COLOR In this case, the language really does maintain two dijoint namespaces. The capitalization scheme is just a convention; Eiffel is actually case-insensitive, but it uses syntactic context to decide which namespace to use at any given point. -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-06 0:00 ` John G. Volan @ 1998-09-07 0:00 ` Brian Rogoff 1998-09-07 0:00 ` John G. Volan 0 siblings, 1 reply; 138+ messages in thread From: Brian Rogoff @ 1998-09-07 0:00 UTC (permalink / raw) On Sun, 6 Sep 1998, John G. Volan wrote: > Brian Rogoff wrote: > > On Sun, 6 Sep 1998, John G. Volan wrote: > > > Funny, I'd say its precisely this quality that should make _Type the > > > *first* resort! :-) It's so generally applicable as a type-marking > > > suffix one might as well use it everywhere... > > > > Exactly my line of thinking too :-|. This is one of the reason's I like > > the Dylan convention of delimiting type names with angle brackets; this > > convention has the pleasing (to me) effect of making type names look very > > different from other lexical items. > > I assume this makes it possible to do something like: > > Car : <Car>; > Color : <Color>; > > In other words, the Dylan convention yields what are effectively two > completely disjoint namespaces for object names and type names. The > marking clearly indicates which namespace a given identifier belongs to. > But except for the marking, identifiers in the two namespaces could be > identical. Exactly. Its a convention, the same one as the _Type convention for Ada, except that it is used consistently in the base Dylan language, and I personally find it easier to read than _Type. I'm aware that opinions will differ. > Compare that with the style convention in Eiffel, where all-uppercase > is used for type names and all-lowercase (or mixed case) is used for > entity names. e.g. > > car : CAR > color : COLOR > > In this case, the language really does maintain two dijoint namespaces. > The capitalization scheme is just a convention; Eiffel is actually > case-insensitive, but it uses syntactic context to decide which > namespace to use at any given point. I don't like this, but I imagine if I spend every day for a few days staring at consistently formatted Eiffel code I'd come around. However, I'd also suggest that some amount of type inference in the language would remove some of the burden of name invention, and thats generally a good thing. No comment on your new signature ;-). -- Brian ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-07 0:00 ` Brian Rogoff @ 1998-09-07 0:00 ` John G. Volan 1998-09-16 0:00 ` Matthew Heaney 0 siblings, 1 reply; 138+ messages in thread From: John G. Volan @ 1998-09-07 0:00 UTC (permalink / raw) Brian Rogoff wrote: > > No comment on your new signature ;-). Heh, there's something to be said about being able to express a disclaimer as something more than a comment ... :-) -- class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-07 0:00 ` John G. Volan @ 1998-09-16 0:00 ` Matthew Heaney 0 siblings, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-09-16 0:00 UTC (permalink / raw) "John G. Volan" <johnvolan@sprintmail.com> writes: > class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant > disclaimer: not (opinion implies employer.opinion) > end -- class JOHN_VOLAN_SIGNATURE That Ada doesn't have an implication operator is a real bummer. It makes it difficult to state a postcondition: not (opinion implies employer.opinion) = not (not opinion or employer.opinion) = opinion and not employer.opinion I would say the form using implication is more clear, eh? ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-06 0:00 ` Matthew Heaney 1998-09-06 0:00 ` John G. Volan @ 1998-09-06 0:00 ` John G. Volan 1 sibling, 0 replies; 138+ messages in thread From: John G. Volan @ 1998-09-06 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > "John G. Volan" <johnvolan@sprintmail.com> writes: > > > Look, I provided you with one puzzle to solve, but you insist on solving > > a different one, one that's easier for you to fit into your scheme. > > Okay, fine, but how about solving my puzzle, too? What if -- what if > > -- you were presented with a problem domain where there are cars, and > > there are colors, and there are other things that can have colors, and > > any car can get any of the colors? For me, if I were coding in Ada, it > > would be simple: > > I don't accept your argument, because I don't accept your premise. > > I can only speak from my own experience. And from my own experience, > color types, and speed types, and heading types, don't exist > independently of higher level abstractions, like cars, and targets, and > airframes, and ownships, etc. Alright then, if "secondary" abstractions just keep distracting you from my point, forget about the secondary abstractions. What about the primary abstractions themselves? My point is about primary abstractions anyway. It may be comforting to you to keep focusing on secondary abstractions, because your naming scheme works so well for them: The primary abstractions they are attached to are such a convenient source for the expendable prefix you need. But where do you get an expendable prefix for a primary abstraction? I was trying to get you to see that your scheme was ad-hoc, because there really is no general source of expendable prefixes for primary abstractions. To demonstrate the dilemma, I was hoping, for the sake of example, that you'd be able to treat the notion of "color" as a primary abstraction (I even sketched how it might look as a private type), but for some reason you seem stuck on "color" being just a secondary abstraction (implemented as a scalar type). If it will help, try a different example: with Patients; use Patients; package Doctors is type Doctor_Type is ... private; procedure Treat_Patient (Doctor : in out Doctor_Type; Patient : in out Patient_Type); procedure Bill_Patient (Doctor : in out Doctor_Type; Patient : in out Patient_Type); ... end Doctors; Here, the problem-domain concepts of "doctor" and "patient" are treated as primary abstractions, each implemented as a private type encapsulated in a separate package. Cohen naming style has been systematically applied: From the problem-domain terminology of "doctor" and "patient", the package names have been derived by taking the plurals, and the type names have been derived by appending "_Type". This leaves the simple form of the terms free to use as nondescript instance names, such as the formal parameters of procedures like Treat_Patient and Bill_Patient. Starting from the same problem domain concepts, "doctor" and "patient", what names would your technique generate for the packages, the types, and the nondescript formal parameters? > If you have a compelling need to declare an enumerated color type (say), > for use by multiple abstractions, then go ahead and name it Color_Type: > > package Color_Types is > > type Color_Type is (...); > > end Color_Types; See above, and see my previous post: I had Color_Type as private type, not just an enumerated type. It had operations allowing a color to be formed from percentages of red, green, and blue components. That's a significant enough abstraction to warrant its own package, and you wouldn't want to repeat all that code in client packages like "Cars". > My philosophy is to use the name _Type only as a last resort, as it has > a sort of generic quality to it. That sometimes turns out to be useful, > as in the example above. Some guys name generic formal types _Type, for > exactly that reason. > But if I'm implementing a car abstraction that had a color attribute, > then I would name the color type Car_Color. > > You point out a problem with this scheme, and that is if there are two > color objects in the same scope. You correctly observed that my use of > an abbreviation in that case wouldn't be necessary if I had used the > name _Type. No, the example was two different _types_ used in the same context: File_Mode and Operational_Mode; which, after jettisoning their "expendable" prefixes, yield the same variable name: Mode. -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-31 0:00 ` Matthew Heaney 1998-08-31 0:00 ` Tucker Taft 1998-09-04 0:00 ` John G. Volan @ 1998-09-04 0:00 ` John G. Volan 1998-09-05 0:00 ` John G. Volan 1998-09-06 0:00 ` Matthew Heaney 1998-09-04 0:00 ` John G. Volan ` (2 subsequent siblings) 5 siblings, 2 replies; 138+ messages in thread From: John G. Volan @ 1998-09-04 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > "John G. Volan" <johnvolan@sprintmail.com> writes: > > > With all these various cases, isn't your scheme really ad hoc? > > I wouldn't describe what I do as ad hoc. If you've read the code in my > other posts, I'm sure you wouldn't describe it as ad hoc either. You > might even be tempted to say it's sorta elegent. I did read your posts, and I saw your code examples. To me, personally, your style strikes me as ad-hoc. I've already given rationales for why I feel that way, a couple of times now. I guess we'll just have to agree to disagree. > > If you claim it is not ad hoc, can you articulate a finite number of > > rules that cover all situations (or at least a sufficient majority of > > them)? > > Hmmm. Let's see. > > 1) Name the (abstract) root of a hierarchy of tagged types Root_. > > One exception (oops, an exception already, on the first bullet!) And from that one would conclude ... what? ;-) > is if > there's already a good two-part name from the problem domain, use that > instead of Root_. The classic example is Bank_Account, from which > Checking_Account and Savings_Account derive. "Bank_Account" is a good term because it comes straight from the terminology of the problem domain. "Root_Account" is bad because it embeds an implementation detail (the fact that this type happens to be at the root of an inheritance hierarchy) as part of a name. If that design decision should change and a different implementation scheme were applied, the name would suddenly become inappropriate -- even though the entity it denoted was still the same conceptual notion from the problem domain. For instance, suppose you started with "Bank_Account" as the root of your hierarchy, but later expanded the application to include other kinds of accounts, such as "Mutual_Fund_Account", etc. You might have a need for an even more general notion of "Account" that would cover all kinds of accounts. This "Account" type would become the new root of the hierarchy, and "Bank_Account" as well as "Mutual_Fund_Account", etc., would now inherit from it. But if all along you'd been using the name "Root_Account" instead of "Bank_Account", you suddenly have to change the name to something else. Furthermore, who says Checking_Account and Savings_Account aren't themselves the roots of their own sub-hierarchies? Here, you would probably say that "Root_" is unnecessary because these types already have expendable adjective prefixes you can drop. I would say "Root_" was unnecessary in the first place. > 2) Name the type _Type to indicate static polymorphism, ie > > generic > ... > package Stacks_Unbounded is > > type Stack_Type is private; > > generic > ... > package Stacks_Bounded is > > type Stack_Type is private; At one point in this discussion I think I might have grokked your notion of "static polymorphism", but it's gone completely from my head now, and the thread has evaporated. Is it that these generic templates provide alternate implementations of essentially the same interface, but without having a common parent type that they both inherit from? Honestly, I can't understand your rationale for why this property in particular would make "_Type" a good prefix here, but not for other types. > 3) Name scalar types using the units in the name, ie > > type Heading_In_Degrees is ...; This is worth another post. > 4) If you often refer to an acronym, then use expanded name as the type, > > SOI : Signal_Of_Interest; > > PDW : Pulse_Descriptor_Word; See my previous post. > 5) Name arrays _Array, and name the array instance the plural: > > type Stack_Item_Array is > array (Positive range <>) of Stack_Item; > > Items : Stack_Item_Array; Here's how I might handle this: generic type Item_Type is private; package Stacks_Bounded is type Stack_Type (Capacity : Positive) is ... private; ... private type Items_Type is array (Positive range <>) of Item_Type; type Stack_Type (Capacity : Positive) is ... record Top : Natural := 0; Items : Items_Type; end record; end Stacks_Bounded; > 6) Never ever name a scalar type as a plural > > type Tuner_Ids is range 1 .. 4; -- you're a bad boy > I makes zero sense to see this > > Id : Tuner_Ids; Well, this is one restriction I can agree on! type Tuner_Id_Type is range 1 .. 4; -- no plurals! As I've said before, I don't really object to dropping a prefix when the context will let you get away with it: Id : Tuner_Id_Type; But my point is that you cannot in general rely on that. Sooner or later you'll run into a context where the prefix has to be put back: Tuner_Id : Tuner_Id_Type; Amplifier_Id : Amplifier_Id_Type; -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-04 0:00 ` John G. Volan @ 1998-09-05 0:00 ` John G. Volan 1998-09-06 0:00 ` Matthew Heaney 1998-09-06 0:00 ` Matthew Heaney 1 sibling, 1 reply; 138+ messages in thread From: John G. Volan @ 1998-09-05 0:00 UTC (permalink / raw) John G. Volan wrote: > > generic > type Item_Type is private; > package Stacks_Bounded is > type Stack_Type (Capacity : Positive) is ... private; > ... > private > type Items_Type is > array (Positive range <>) of Item_Type; > type Stack_Type (Capacity : Positive) is ... > record > Top : Natural := 0; > Items : Items_Type; -- Woops! Of course, that should be: Items : Items_Type (1 .. Capacity); > end record; > end Stacks_Bounded; -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-05 0:00 ` John G. Volan @ 1998-09-06 0:00 ` Matthew Heaney 0 siblings, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-09-06 0:00 UTC (permalink / raw) "John G. Volan" <johnvolan@sprintmail.com> writes: > > generic > > type Item_Type is private; > > package Stacks_Bounded is > > type Stack_Type (Capacity : Positive) is ... private; > > ... > > private > > type Items_Type is > > array (Positive range <>) of Item_Type; > > type Stack_Type (Capacity : Positive) is ... > > record > > Top : Natural := 0; > > Items : Items_Type; > > -- Woops! Of course, that should be: > Items : Items_Type (1 .. Capacity); > > > end record; > > end Stacks_Bounded; > The reasons for using a generic formal object as the size vs passing it in as a discriminant are explicated in the Ada95 Rationale. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-04 0:00 ` John G. Volan 1998-09-05 0:00 ` John G. Volan @ 1998-09-06 0:00 ` Matthew Heaney 1 sibling, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-09-06 0:00 UTC (permalink / raw) "John G. Volan" <johnvolan@sprintmail.com> writes: > > 2) Name the type _Type to indicate static polymorphism, ie > > > > generic > > ... > > package Stacks_Unbounded is > > > > type Stack_Type is private; > > > > generic > > ... > > package Stacks_Bounded is > > > > type Stack_Type is private; > > At one point in this discussion I think I might have grokked your notion > of "static polymorphism", but it's gone completely from my head now, and > the thread has evaporated. Is it that these generic templates provide > alternate implementations of essentially the same interface, but without > having a common parent type that they both inherit from? Honestly, I > can't understand your rationale for why this property in particular > would make "_Type" a good prefix here, but not for other types. Because this is the style used in the RM. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-31 0:00 ` Matthew Heaney ` (2 preceding siblings ...) 1998-09-04 0:00 ` John G. Volan @ 1998-09-04 0:00 ` John G. Volan 1998-09-05 0:00 ` Matthew Heaney 1998-09-05 0:00 ` John G. Volan 1998-09-05 0:00 ` John G. Volan 5 siblings, 1 reply; 138+ messages in thread From: John G. Volan @ 1998-09-04 0:00 UTC (permalink / raw) [I just noticed that Matthew picked up this thread again over here on comp.lang.ada. There's a lot to comment on, so I may need more than one post.] Matthew Heaney wrote: > > "John G. Volan" <johnvolan@sprintmail.com> writes: > > > Ada's mechanism is to force the identifiers to be literally different, > > which means either adding some kind of noise word to one or the other, > > or resorting to abbreviation for one or the other. Many react with > > distaste to either prospect, because they recognize both as catering > > to the programming language, and not to the problem domain concept we > > are trying to express. (Remember, the noun phrase in question is > > presumed to be both necessary and sufficient to express the concept.) > > Adding noise seems less obnoxious than abbreviation. So what's the > > least obnoxious noise you can add? > > I do this sort of thing too: > > PDW : Pulse_Descriptor_Word; > > SOI : Signal_Of_Interest; I thought one assumption in this discussion was that we were trying to find schemes that would allow us to avoid abbreviations. But if abbreviations were fair game, then there would never have been an issue: type Color is ... type Car is record C : Color; ... end record; C : Car; ... C.C ... -- so nice and readable! :-) However, I think we can do a lot better than that ... [...snip...] > > On the other hand, let's suppose "File_Mode" is a necessary and > > sufficient phrase to express the whole sense of the concept > > (presumably within a use-ophilic environment). Maybe you can get away > > with dropping the "File_" adjective for a variable within the package, > > but can you always do that outside the package, in all its conceivable > > clients? What if there's a context where you have both a "File_Mode" > > and some other kind of mode, say an "Operational_Mode" (e.g., Real vs. > > Simulated)? Then it becomes important to use the complete names for > > those concepts, including the "File_" and "Operational_" prefixes, not > > just in their type names but also in the variable names. If we now > > need "File_Mode" and "Operational_Mode" as variable names, what should > > the types have been called? > > That does happen sometimes, especially subprogram parameters. I would > probably do something like this: > > procedure Op > (File : in out File_Type; > FMode : in File_Mode; > OMode : in Operation_Mode); So when push comes to shove, you advocate that we give up on English and resort to ad-hoc abbreviations? Why "FMode" and "OMode", particularly? Why not "Filmod" and "Opmod"? or "FileM" and OperatM"? Indeed, why not just "FM" and "OM"? When I code, one principle I strive for is "No Synonyms": As much as possible, I'll try to use exactly one term to designate one concept. When that term is expressed in full English words (e.g., "File_Mode"), it's not too hard to keep to a single spelling. But once you start abbreviating, it's too easy to proliferate a lot of alternate abbreviations for the same thing, even in the same code module! I've seen it happen, and it's not pretty. You can say it's a matter of taste, but a lot of what we've been discussion is just taste. -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-04 0:00 ` John G. Volan @ 1998-09-05 0:00 ` Matthew Heaney 1998-09-05 0:00 ` John G. Volan 0 siblings, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-09-05 0:00 UTC (permalink / raw) "John G. Volan" <johnvolan@sprintmail.com> writes: > > I do this sort of thing too: > > > > PDW : Pulse_Descriptor_Word; > > > > SOI : Signal_Of_Interest; > > I thought one assumption in this discussion was that we were trying to find > schemes that would allow us to avoid abbreviations. But if abbreviations > were fair game, then there would never have been an issue: Those happen to be the terms people on our project really use to refer to the entity. "What was the value of the pee dee double-yew?" "What's the ess oh eye?" ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-09-05 0:00 ` Matthew Heaney @ 1998-09-05 0:00 ` John G. Volan 0 siblings, 0 replies; 138+ messages in thread From: John G. Volan @ 1998-09-05 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > "John G. Volan" <johnvolan@sprintmail.com> writes: > > > > I do this sort of thing too: > > > > > > PDW : Pulse_Descriptor_Word; > > > > > > SOI : Signal_Of_Interest; > > > > I thought one assumption in this discussion was that we were trying to find > > schemes that would allow us to avoid abbreviations. But if abbreviations > > were fair game, then there would never have been an issue: > > Those happen to be the terms people on our project really use to refer > to the entity. "What was the value of the pee dee double-yew?" "What's > the ess oh eye?" Abbreviations per se are not evil. If an abbreviation or acronym is well-known and well-established in a given problem domain (e.g. your PDW or SOI), then it's a legitimate candidate for the name of a program entity. Rather, it's _ad-hoc_ abbreviations that are evil, abbreviations that a programmer invents on the spot for his own convenience but without any basis from the problem domain. (For instance, your "FMode" and "OMode" for "File_Mode" and "Operational_Mode", when you were forced to disambiguate "Mode" in a specific context.) But if well-established abbreviations like PDW and SOI are good names, then they're good not just as variable names, but also as type names -- and we're back to square one! The problem with using a legitimate abbreviation like SOI _and_ the fully-spelled out term Signal_Of_Interest within the same program is that these verge on being synonyms of each other, and this might be construed as a violation of the "No Synonyms" principle. (Whether you want to subscribe to that principle, is of course up to you.) What this principle seeks to avoid is situations like this: Position : Location; Direction : Azimuth; Point : Vertex; It would be better either to have: Position : Position_Type; Direction : Direction_Type; Point : Point_Type; or this would be okay: Location : Location_Type; Azimuth : Azimuth_Type; Vertex : Vertex_Type; In other words, for each concept from your problem domain, use just one term for it in your program text. According to that principle, the following would be okay: PDW : PDW_Type; SOI : SOI_Type; -- as long as these acronyms were documented in the official -- project acronym list and the programmers were trained or this would be okay: Pulse_Descriptor_Word : Pulse_Descriptor_Word_Type; Signal_Of_Interest : Signal_Of_Interest_Type; but NOT this: PDW : Pulse_Descriptor_Word; SOI : Signal_Of_Interest; Of course, that's a pretty strict reading of the No Synonyms principle. Is an acronym _really_ a distinct synonym for the spelled-out term? One could argue that it's just an alternate _form_ for that term, so why not allow both? The problem is that this is a slippery slope. If programmers start out with supposedly legitimate cases like "SOI: Signal_Of_Interest" and get used to that as a pattern, it's just too tempting to slide into ad-hoc cases like "FM: File_Mode" when the going gets tough. How do you tell an ad-hoc abbreviation from a legitimate one? If you see a given abbreviation on a page, what feature of it will leap out and tell you whether it's in the approved list or it's something the programmer made up on the spot? The answer is, nothing. Unless you're an extreme expert on the problem domain (and not all programmers are), you'd need to go check the list. Another argument against cases like "SOI: Signal_Of_Interest" is this: If "SOI" and "Signal_Of_Interest" are just two equally-good forms of the same term, then why not give the programmer the discretion to choose _either_ form, anyplace where that term comes up in the program? In other words: type Signal_Of_Interest_Type is ... ; subtype SOI_Type is Signal_Of_Interest_Type; -- using a subtype as a "renaming" for a type And then let each programmer choose either to use SOI : SOI_Type; or to use Signal_Of_Interest : Signal_Of_Interest_Type; at their own discretion. Another way of putting it is: Why lock up the spell-out form of a term like "Signal_Of_Interest" as a type name? That prevents programmers from using it as a variable name when they want to. You're essentially _forcing_ them to use the abbreviation when they want to name their variables. -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-31 0:00 ` Matthew Heaney ` (3 preceding siblings ...) 1998-09-04 0:00 ` John G. Volan @ 1998-09-05 0:00 ` John G. Volan 1998-09-05 0:00 ` John G. Volan 5 siblings, 0 replies; 138+ messages in thread From: John G. Volan @ 1998-09-05 0:00 UTC (permalink / raw) [Apologies if this turns out to be a re-post. Having some problems with my newsfeed...] Matthew Heaney wrote: > > "John G. Volan" <johnvolan@sprintmail.com> writes: > > > > I do this sort of thing too: > > > > > > PDW : Pulse_Descriptor_Word; > > > > > > SOI : Signal_Of_Interest; > > > > I thought one assumption in this discussion was that we were trying to find > > schemes that would allow us to avoid abbreviations. But if abbreviations > > were fair game, then there would never have been an issue: > > Those happen to be the terms people on our project really use to refer > to the entity. "What was the value of the pee dee double-yew?" "What's > the ess oh eye?" Abbreviations per se are not evil. If an abbreviation or acronym is well-known and well-established in a given problem domain (e.g. your PDW or SOI), then it's a legitimate candidate for the name of a program entity. Rather, it's _ad-hoc_ abbreviations that are evil, abbreviations that a programmer invents on the spot for his own convenience but without any basis from the problem domain. (For instance, your "FMode" and "OMode" for "File_Mode" and "Operational_Mode", when you were forced to disambiguate "Mode" in a specific context.) But if well-established abbreviations like PDW and SOI are good names, then they're good not just as variable names, but also as type names -- and we're back to square one! The problem with using a legitimate abbreviation like SOI _and_ the fully-spelled out term Signal_Of_Interest within the same program is that these verge on being synonyms of each other, and this might be construed as a violation of the "No Synonyms" principle. (Whether you want to subscribe to that principle, is of course up to you.) What this principle seeks to avoid is situations like this: Position : Location; Direction : Azimuth; Point : Vertex; It would be better either to have: Position : Position_Type; Direction : Direction_Type; Point : Point_Type; or this would be okay: Location : Location_Type; Azimuth : Azimuth_Type; Vertex : Vertex_Type; In other words, for each concept from your problem domain, use just one term for it in your program text. According to that principle, the following would be okay: PDW : PDW_Type; SOI : SOI_Type; -- as long as these acronyms were documented in the official -- project acronym list and the programmers were trained or this would be okay: Pulse_Descriptor_Word : Pulse_Descriptor_Word_Type; Signal_Of_Interest : Signal_Of_Interest_Type; but NOT this: PDW : Pulse_Descriptor_Word; SOI : Signal_Of_Interest; Of course, that's a pretty strict reading of the No Synonyms principle. Is an acronym _really_ a distinct synonym for the spelled-out term? One could argue that it's just an alternate _form_ for that term, so why not allow both? The problem is that this is a slippery slope. If programmers start out with supposedly legitimate cases like "SOI: Signal_Of_Interest" and get used to that as a pattern, it's just too tempting to slide into ad-hoc cases like "FM: File_Mode" when the going gets tough. How do you tell an ad-hoc abbreviation from a legitimate one? If you see a given abbreviation on a page, what feature of it will leap out and tell you whether it's in the approved list or it's something the programmer made up on the spot? The answer is, nothing. Unless you're an extreme expert on the problem domain (and not all programmers are), you'd need to go check the list. Another argument against cases like "SOI: Signal_Of_Interest" is this: If "SOI" and "Signal_Of_Interest" are just two equally-good forms of the same term, then why not give the programmer the discretion to choose _either_ form, anyplace where that term comes up in the program? In other words: type Signal_Of_Interest_Type is ... ; subtype SOI_Type is Signal_Of_Interest_Type; -- using a subtype as a "renaming" for a type And then let each programmer choose either to use SOI : SOI_Type; or to use Signal_Of_Interest : Signal_Of_Interest_Type; at their own discretion. Another way of putting it is: Why lock up the spell-out form of a term like "Signal_Of_Interest" as a type name? That prevents programmers from using it as a variable name when they want to. You're essentially _forcing_ them to use the abbreviation when they want to name their variables. -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-31 0:00 ` Matthew Heaney ` (4 preceding siblings ...) 1998-09-05 0:00 ` John G. Volan @ 1998-09-05 0:00 ` John G. Volan 5 siblings, 0 replies; 138+ messages in thread From: John G. Volan @ 1998-09-05 0:00 UTC (permalink / raw) [Cross-posted to comp.lang.eiffel, since I've added Eiffel content] Matthew Heaney wrote: > > "John G. Volan" <johnvolan@sprintmail.com> writes: > [...snip...] > 3) Name scalar types using the units in the name, ie > > type Heading_In_Degrees is ...; [...snip...] > > As I've pointed out in the past, if it's important to say something in > > a type name, there could easily be a case where it's important to say > > it in the variable name too: > > > > Speed_In_MPH : Speed_In_MPH_Type; > > Speed_In_Knots : Speed_In_Knots_Type; > > ... > > Speed_In_Knots := To_Knots(Speed_In_MPH); > > See my point above. > > The times when I care about the specific units of speed are only a > subset of all the times I manipulate a speed. When I really do care > about the units, I just navigate to the declaration, the read units from > the type name. > > You don't need to tell me the units every single time, because I don't > care about units every single time. And when I don't care, I have to > mentally parse it out. I'm not saying that such details need to be stated at _all_ times. I can accept dropping prefixes and suffixes if the context allows, e.g.: type Ship_Type is record Speed : Speed_In_Knots_Type; ... end record; Ship : Ship_Type; ... Ship.Speed ... -- we can look up the declaration to remind us of -- the units I'm merely saying that these suffixes and prefixes may be needed at _some_ time, when the context forces us to disambiguate things, as in my example you quoted above. If you had to do the above conversion using your naming scheme, how would you declare the two different "speed" objects? You rely on being able to drop a unit suffix to generate a variable name distinct from the type name. But in the above situation, these suffixes are needed again to disambiguate the two variables, which otherwise would have wound up with the same name according to your scheme. If your answer is, "Well, I'll just come up with some abbreviations for the speed in knots variable vs. the speed in mph variable," then I'd say, okay, you're free to do so, but then you'd have to admit that you were doing something ad-hoc. Remember, the reason we're forced into all these contortions is because of Ada's case insensitivity, combined with its strict insistence that type names and variable names share a single namespace (within a given scope). In a language that relaxes either of these properties, we don't have a problem. For instance, in Eiffel we might have: expanded class SPEED_IN_MPH inherit DOUBLE feature ... end expanded class SPEED_IN_KPH inherit DOUBLE feature ... end expanded class SPEED_IN_KNOTS inherit DOUBLE feature ... end class SHIP feature speed: SPEED_IN_KNOTS ... end -- class SHIP And the above conversion situation would be something like: speed_in_mph: SPEED_IN_MPH; speed_in_knots: SPEED_IN_KNOTS; ... speed_in_knots := to_knots (speed_in_mph) > > Or perhaps we should consider the word "Speed" to be unnecessary noise: > > > > MPH : MPH_Type; > > Knots : Knots_Type; > > ... > > Knots := To_Knots(MPH); > > ... > > Set_Speed (Car, MPH => 10.0); > > > > Perhaps "Speed" could be the name of the package that houses the > > MPH_Type and Knots_Type, and the To_Knots function, etc... > > I don't like this idea. The characteristics of the supporting type, > such as whether it's fixed or float, the digits of precision, range, > etc, are determined by the larger abstraction. So I usually place the > attribute types there, with the abstraction they describe. If I'm reading this right, what you're saying is that if an analysis of the problem domain indicates that a car has a speed in miles per hour, you'd put a Car_Speed_In_MPH type in the Cars package along with a <Something>_Car type? Suppose further analysis of the problem domain indicated that weather conditions constituted an important abstraction (let's say the system does fine engine and transmission control to improve traction and fuel economy in adverse weather). Then you might have a Wind_Speed_In_MPH type in a Weather package. Would these two speed types have no commonality? Would you be forced to do a lot of type-conversions to work with them both? Why couldn't you just have a single Speed_In_MPH_Type in a common package (regarding Speeds) that could be shared between the Cars package and the Weather package? I've often noted that Ada projects tend to proliferate a lot of unnecessary, redundant representations for the same classes of physical quantities. Little attempt is made to standardize on a normalized set of unit types and accuracies, so you wind up with a lot of complex, redundant, and hard to maintain conversion code scattered all over the system. Such projects might have benefited greatly if physical quantity types had been treated as first-class abstractions in their own right, e.g.: package Speeds is type Speed_Type is private; function From_MPH (MPH : in Long_Float) return Speed_Type; function From_KPH (KPH : in Long_Float) return Speed_Type; function From_Knots (Knots : in Long_Float) return Speed_Type; ... function To_MPH (Speed : in Speed_Type) return Long_Float; function To_KPH (Speed : in Speed_Type) return Long_Float; function To_Knots (Speed : in Speed_Type) return Long_Float; ... private type Speed_Type is record MPH : Long_Float; -- arbitrary choice, might be changed -- without affecting the abstraction end record; end Speeds; with Speed_Constants; use Speed_Constants; package body Speeds is function From_MPH (MPH : in Long_Float) return Speed_Type is begin return (MPH => MPH); end From_MPH; function From_KPH (KPH : in Long_Float) return Speed_Type is begin return (MPH => KPH * KPH_To_MPH); end From_KPH; function From_Knots (Knots : in Long_Float) return Speed_Type is begin return (MPH => Knots * Knots_To_MPH); end From_Knots; ... function To_MPH (Speed : in Speed_Type) return Long_Float is begin return Speed.MPH; end To_MPH; function To_KPH (Speed : in Speed_Type) return Long_Float is begin return Speed.MPH * MPH_To_KPH; end To_KPH; function To_Knots (Speed : in Speed_Type) return Long_Float is begin return Speed.MPH * MPH_To_Knots; end To_Knots; ... end Speed; Here's a similar rendition in Eiffel: expanded class SPEED inherit SPEED_CONSTANTS; -- assume provides Mph_to_kph, Kph_to_mph, etc... DOUBLE_APPROXIMATION -- assume provides comparison functions that account -- for numeric inprecision in DOUBLE computations, e.g.: -- sufficiently_equal, sufficiently_greater, etc. -- Are such functions already available somewhere? feature mph: DOUBLE -- this happens to be the only attribute, -- but that is an arbitrary choice. The rest -- are conversion functions: kph: DOUBLE is do Result := mph * Mph_to_kph end knots: DOUBLE is do Result := mph * Mph_to_knots end ... set_mph (new_mph: DOUBLE) is do mph := new_mph ensure sufficiently_equal (mph, new_mph) end set_kph (new_kph: DOUBLE) is do mph := new_kph * Kph_to_mph ensure sufficiently_equal (kph, new_kph) end set_knots (new_knots: DOUBLE) is do mph := new_knots * Knots_to_mph ensure sufficiently_equal (knots, new_knots) end accelerate (delta_speed: SPEED) is do mph := mph + delta_speed.mph ensure sufficiently_equal (mph, mph + delta_speed.mph) end ... invariant kph_definition: sufficiently_equal (mph * Mph_to_kph, kph); knots_definition: sufficiently_equal (mph * Mph_to_knots, knots); ... end -- class SPEED An intriguing alternative possibility would be to make SPEED a deferred class instead (an abstract type in Ada95 parlance): deferred class SPEED inherit SPEED_CONSTANTS; -- assume provides Mph_to_kph, Kph_to_mph, etc... DOUBLE_APPROXIMATION -- assume provides comparison functions that account -- for numeric inprecision in DOUBLE computations, e.g.: -- sufficiently_equal, sufficiently_greater, etc. -- Are such functions already available somewhere? feature mph: DOUBLE is deferred end kph: DOUBLE is deferred end knots: DOUBLE is deferred end ... set_mph (new_mph: DOUBLE) is deferred ensure sufficiently_equal (mph, new_mph) end set_kph (new_kph: DOUBLE) is deferred ensure sufficiently_equal (kph, new_kph) end set_knots (new_knots: DOUBLE) is deferred ensure sufficiently_equal (knots, new_knots) end accelerate (delta_speed: SPEED) is require delta_speed_exists: delta_speed /= Void deferred ensure sufficiently_equal (mph, mph + delta_speed.mph) end ... invariant kph_definition: sufficiently_equal (mph * Mph_to_kph, kph); knots_definition: sufficiently_equal (mph * Mph_to_knots, knots); ... end -- class SPEED Then, you could have different heirs of this class optimized for specific units of measure: expanded class SPEED_IN_MPH inherit SPEED feature mph: DOUBLE kph: DOUBLE is do Result := mph * Mph_to_kph end knots: DOUBLE is do Result := mph * Mph_to_knots end ... accelerate (delta_speed: SPEED) is do mph := mph + delta_speed.mph end ... end -- class SPEED_IN_MPH expanded class SPEED_IN_KPH inherit SPEED feature mph: DOUBLE is do Result := kph * Kph_to_mph end kph: DOUBLE knots: DOUBLE is do Result := kph * Kph_to_knots end ... accelerate (delta_speed: SPEED) is do kph := kph + delta_speed.kph end ... end -- end class SPEED_IN_KPH ... similarly for SPEED_IN_KNOTS, etc. Then a class like CAR could have a SPEED attribute that could avail itself of polymorphism: class CAR creation make feature -- Status report speed: SPEED feature -- Status setting set_speed (new_speed: SPEED) is require speed_exists: new_speed /= Void do speed := new_speed; end ... feature {NONE} -- Initialization make is do ... !SPEED_IN_MPH! speed -- default to optimize on miles per hour, -- but can be changed later (via set_speed) -- to optimize on other units ... end ... invariant speed_exists: speed /= Void ... end -- class CAR -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-08 0:00 ` Matthew Heaney 1998-08-08 0:00 ` John G. Volan @ 1998-08-11 0:00 ` doylep 1 sibling, 0 replies; 138+ messages in thread From: doylep @ 1998-08-11 0:00 UTC (permalink / raw) In article <m3pveclhna.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: > > doylep@ecf.toronto.edu writes: > > > class CAR > > > > feature > > steering_wheel : STEERING_WHEEL > > > > end > > > > What else are you going to call the steering wheel? A > > direction_control_device? I think any other name would be contrived. > > I usually qualify auxiliary types with the name of the "main" type, so I > probably would have named the type Car_Steering_Wheel, and the object > Steering_Wheel. Doesn't this policy significantly hamper the OO process? IMHO, OO is about looking for common abstractions; coming up with one-shot abstractions is far less conducive to reuse. Thus, I'd very much prefer calling the class "Steering_wheel" and finding abstractions common to *all* steering wheels. Then I could reuse this class in any application requiring steering wheels. If a car's steering wheel is really different, it could be its own subclass. -PD -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-05 0:00 ` Brian Rogoff 1998-08-07 0:00 ` doylep @ 1998-08-07 0:00 ` Don Harrison 1 sibling, 0 replies; 138+ messages in thread From: Don Harrison @ 1998-08-07 0:00 UTC (permalink / raw) Brian Rogoff wrote (in com.lang.ada): :On Wed, 5 Aug 1998, Don Harrison wrote: :> Matt Heaney wrote: :> :> :In an Ada declaration, the object and the type can't have the same name. :> :If the object is called File, then the type has to be called something :> :else. (Note that Eiffel doesn't have this "problem," because the object :> :and its type are in different namespaces.) :> :> I think it's not so much namespaces but the fact that the syntax allows :> you (and the compiler) to easily differentiate variables (entities in :> Eiffel parlance) from types. : :Well, I hate to agree with my mortal enemy Matthew :-), It's easy to make a friend of an enemy when arguing with an even greater "enemy". :) :"but for this to be :correct it would have to be the case that Ada syntax doesn't allow you to :differentiate types and variables in the analogous Ada constructs. No. That's a necessary, but not sufficient, condition. It's also necessary that the compiler actually *uses* this semantic information to disambiguate. In the case of Eiffel, it does; in the case of Ada, it doesn't. :at least for your examples, this is obviously not true. So Matthew's point :stands, it is the separate namespaces, not the syntax, that allows you to :use the same names for types and variables. Your inference is wrong due to a false assumption. :I find that very ugly, but I'm :sure if I used Eiffel long enough my abhorence would diminish. If I continue to use Ada, my abhorence of having to (unecessarily) invent different names will remain. :) Don. Don Harrison donh at syd.csa.com.au ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-05 0:00 ` Don Harrison 1998-08-05 0:00 ` Brian Rogoff @ 1998-08-05 0:00 ` Matthew Heaney 1998-08-07 0:00 ` Don Harrison 1 sibling, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-08-05 0:00 UTC (permalink / raw) nospam@thanks.com.au (Don Harrison) writes: > I think it's not so much namespaces but the fact that the syntax allows > you (and the compiler) to easily differentiate variables (entities in > Eiffel parlance) from types. > > Some examples.. > > 1) Variable declarations: > > variable : TYPE > > The identifier to the left of the colon is recognised as a variable > and the one on the right as a type. But this is true in Ada too. The issue in Ada is that once an identifier appears in a declaration, it can't appear again in the same declaration. So the declaration declare File : File; begin is illegal in Ada, even though the compiler knows that the identifier on the left denotes an object, and the identifier on the right a type. The same is true for function invokations (aka "constructors") that appear in a declaration. The declaration declare Top : Integer renames Top (Integer_Stack); begin is illegal, because of the name clash between object Top and selector Top. That's why I usually name selectors Get_xxx, to avoid namespace conflicts inside a declaration. The declaration declare Top : Integer renames Get_Top (Integer_Stack); begin is now legal. I argue that different names should be used for an object and its type in a declaraion, in order to prevent namespace clashes. I don't think an expanded name (ie P.T) should be used for this purpose. I make this argument based on a careful reading of the RM. File_Type is called that precisely because an object of that type will most likely be called File. Had the designers intended for expanded name notation to always be used for the type in an object declaration, in order to resolve a name clash, then File_Type would have been named just File. As much as possible, I like to stick to the naming conventions in the RM. But this is my model. For others, consistency with RM conventions isn't a compelling enough argument. Oh, well. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-05 0:00 ` Matthew Heaney @ 1998-08-07 0:00 ` Don Harrison 1998-08-13 0:00 ` Robert A Duff 0 siblings, 1 reply; 138+ messages in thread From: Don Harrison @ 1998-08-07 0:00 UTC (permalink / raw) Matt Heaney wrote (in comp.lang.ada): :In an Ada declaration, the object and the type can't have the same name. : .. (Note that Eiffel doesn't have this "problem," because the object :and its type are in different namespaces.) to which I replied: :> I think it's not so much namespaces but the fact that the syntax allows :> you (and the compiler) to easily differentiate variables (entities in :> Eiffel parlance) from types. :> :> Some examples.. :> :> 1) Variable declarations: :> :> variable : TYPE :> :> The identifier to the left of the colon is recognised as a variable :> and the one on the right as a type. : :But this is true in Ada too. The point is that Ada doesn't use that information to disambiguate, whereas Eiffel does. Eiffel syntax is puposefully designed to leave no ambiguity as to what is a type and what is an entity - presumably so redundant information such as "_TYPE" can be omitted. It is the syntax, not different namespaces, that's responsible for the removal of ambiguity. The entity and its type happen to be defined in different modules, but that isn't why there is no ambiguity. If Eiffel syntax permitted it, they could be defined in the *same* namespace and there would still be no problem. The question is: In Ada, is all syntax involving entities and types similarly unambiguous? If so, the requirement, in Ada, that an entity and it's type have different names is an unnecessary one. Don. Don Harrison donh at syd.csa.com.au ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-07 0:00 ` Don Harrison @ 1998-08-13 0:00 ` Robert A Duff 1998-08-14 0:00 ` adam 1998-08-14 0:00 ` Don Harrison 0 siblings, 2 replies; 138+ messages in thread From: Robert A Duff @ 1998-08-13 0:00 UTC (permalink / raw) nospam@thanks.com.au (Don Harrison) writes: > In Ada, is all syntax involving entities and types similarly unambiguous? > If so, the requirement, in Ada, that an entity and it's type have different > names is an unnecessary one. Almost, but not quite. Eg, "Mumble'First" is a legal expression whether Mumble is a type or an array object. And "pragma Import(Eiffel, Mumble);" is legal for practically any sort of Mumble. - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-13 0:00 ` Robert A Duff @ 1998-08-14 0:00 ` adam 1998-08-14 0:00 ` Don Harrison 1 sibling, 0 replies; 138+ messages in thread From: adam @ 1998-08-14 0:00 UTC (permalink / raw) In article <wccemukwnx9.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > nospam@thanks.com.au (Don Harrison) writes: > > > In Ada, is all syntax involving entities and types similarly unambiguous? > > If so, the requirement, in Ada, that an entity and it's type have different > > names is an unnecessary one. > > Almost, but not quite. Eg, "Mumble'First" is a legal expression whether > Mumble is a type or an array object. And "pragma Import(Eiffel, Mumble);" > is legal for practically any sort of Mumble. Also, Mumble(X) could be either an array element or a type conversion. -- Adam -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-13 0:00 ` Robert A Duff 1998-08-14 0:00 ` adam @ 1998-08-14 0:00 ` Don Harrison 1 sibling, 0 replies; 138+ messages in thread From: Don Harrison @ 1998-08-14 0:00 UTC (permalink / raw) Bob Duff wrote: :nospam@thanks.com.au (Don Harrison) writes: : :> In Ada, is all syntax involving entities and types similarly unambiguous? :> If so, the requirement, in Ada, that an entity and it's type have different :> names is an unnecessary one. : :Almost, but not quite. Eg, "Mumble'First" is a legal expression whether :Mumble is a type or an array object. And "pragma Import(Eiffel, Mumble);" :is legal for practically any sort of Mumble. Thanks for the clarification. Without checking, it appears there are few such ambiguities, so it might be possible to remove them in a future revision if considered worthwhile. Don. Don Harrison donh at syd.csa.com.au ^ permalink raw reply [flat|nested] 138+ messages in thread
* Static Polymorphism (Was Re: Naming of Tagged Types...) 1998-07-30 0:00 ` Matthew Heaney 1998-07-30 0:00 ` dennison 1998-08-01 0:00 ` Simon Wright @ 1998-08-05 0:00 ` Brian Rogoff 1998-08-06 0:00 ` Matthew Heaney 2 siblings, 1 reply; 138+ messages in thread From: Brian Rogoff @ 1998-08-05 0:00 UTC (permalink / raw) On Thu, 30 Jul 1998, Matthew Heaney wrote: ... snip ... > Because I want a client to be able to easily change the code if he > changes his mind about what kind of stack he needs (say, to go from a > bounded stack to a dynamic stack with a statically allocated heap), I > just named all the stack types Stack_Type. (Brian Rogoff must be > smiling right now...) Just like File_Type. > > This does not mean, however, that you should name every type using the > _Type convention. This is a big mistake, because then the convention > would loose its value as an indicator of static polymorphism. > > For example, the active iterator for the Stack_Type is called > Stack_Iterator. It's not just any Iterator_Type, it's an iterator for > stacks, so call it that. I wonder why you would want to name the iterator type Stack_Iterator, since it seems to defeat the goals you describe for minimal rewriting when changing implementation? For example, if you wanted to replace the stack with a deque, or a singly linked list, you have to rename all occurrences of Stack_Iterator. If you take a look at the collection library at http://www.best.com/~bpr/agl.html which is also "tagged-type-free", you'll see that I copied from the C++ STL, and named the iterators based on the kinds of iteration they support, Unidirectional, Bidirectional, Random_Access, etc., rather than on the data structures they iterate over. This gives you what you are calling "static polymorphism", and allows you to write many algorithms in terms of iterators alone. If you can tolerate reading C++, check out the STL, you'll find that you share some design goals with its authors. -- Brian PS: The sorting routines in my library right now weren't meant to work; I just forgot to yank them out. I'll put real working versions on the net soon, after I figure out whether I want a Swap_Values routine in the iterator signatures... ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Static Polymorphism (Was Re: Naming of Tagged Types...) 1998-08-05 0:00 ` Static Polymorphism (Was Re: Naming of Tagged Types...) Brian Rogoff @ 1998-08-06 0:00 ` Matthew Heaney 1998-08-06 0:00 ` Brian Rogoff 0 siblings, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-08-06 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> writes: > I wonder why you would want to name the iterator type Stack_Iterator, > since it seems to defeat the goals you describe for minimal rewriting > when changing implementation? > > For example, if you wanted to replace the stack with a deque, or a singly > linked list, you have to rename all occurrences of Stack_Iterator. Yes, you would have to change the iterator, but you also have to change all the stack instances, all the operation calls from Push to Add, the selector from Get_Top to Get_Front, etc, etc, etc. So I don't accept the premise of your argument. The reason I chose a stack in the first place is because I needed an ordered collection, that has First-In Last-Out semantics. If my requirements changed, and I needed a collection with different semantics (say, I suddenly need First-In, First-Out) semantics, then it's a Good Thing that I have to change all object declarations from Stack_Type to Queue_Type. If I didn't care about the collection being ordered, then certainly a stack was _not_ the correct choice as my collection abstraction. The correct choice would be a Container_Type, which is an unordered collection. But to go from a stack to a list? Why? These are _really_ different abstractions. A stack is monolithic; a list polylithic. The only time I ever use a list is to implement a monolithic collection like a stack or queue or container. Like an array, a list is a data structure that should only be used to implement higher-level abstractions. Never use a list (or array) directly as a data structure. > If you take a look at the collection library at > http://www.best.com/~bpr/agl.html which is also "tagged-type-free", > you'll see that I copied from the C++ STL, and named the iterators > based on the kinds of iteration they support, Unidirectional, > Bidirectional, Random_Access, etc., rather than on the data structures > they iterate over. This gives you what you are calling "static > polymorphism", and allows you to write many algorithms in terms of > iterators alone. I see your point of view; let me think about it for a while. I only implemented simple, one-way iterators (from front-to-back, or top-to-bottom, etc). The implementation of the data structure can really limit what kinds of iteration it supports. For example, if you want to traverse a stack from bottom to top, you really need to implement the stack using a doubly-linked list, and, you have to have to a bottom pointer in addition to the normal top pointer. I'm not even sure some iteration schemes should be allowed. For example, does it make a lot of sense to have a random-access iterator for a stack? If so, then what's the point of using an ordered collection? And how do you implement a random-access iterator for a stack implemented as a linked list? Probably only one programmer in a thousand needs to randomly access a stack. In that case, he can just write a child to do that special thing he needs. > If you can tolerate reading C++, check out the STL, you'll find that you > share some design goals with its authors. I'd really like to study the STL; I have the Stepanov book. I'd bet I could learn a lot of cool stuff. But, as we have discussed in the past, the STL is a library highly optimized for programming in C++. Trying to apply STL ideas to Ada95 would be like trying to translate argot from French to English - how well does it really translate? In Ada95, a client can write a child package to extend the structure with whatever custom operations the client requires. Maybe that's the better design choice, because it would keep the library simple, instead of trying to anticipate all the myriad variations of iteration. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Static Polymorphism (Was Re: Naming of Tagged Types...) 1998-08-06 0:00 ` Matthew Heaney @ 1998-08-06 0:00 ` Brian Rogoff 0 siblings, 0 replies; 138+ messages in thread From: Brian Rogoff @ 1998-08-06 0:00 UTC (permalink / raw) On Thu, 6 Aug 1998, Matthew Heaney wrote: > Brian Rogoff <bpr@shell5.ba.best.com> writes: > > > I wonder why you would want to name the iterator type Stack_Iterator, > > since it seems to defeat the goals you describe for minimal rewriting > > when changing implementation? > > > > For example, if you wanted to replace the stack with a deque, or a singly > > linked list, you have to rename all occurrences of Stack_Iterator. > > Yes, you would have to change the iterator, but you also have to change > all the stack instances, all the operation calls from Push to Add, the > selector from Get_Top to Get_Front, etc, etc, etc. Fortunately, Ada has renaming, subtypes, etc., etc. > So I don't accept the premise of your argument. The reason I chose a > stack in the first place is because I needed an ordered collection, that > has First-In Last-Out semantics. Thats a stronger argument. An STL like solution is to provide some sort of adaptor on a collection to give the semantics you want. I guess when I'm using Push/Pop/Get_Top/etc I'm not thinking of using iterators anyways, but I'm directly dealing with a stack and its elements. ... snip ... > But to go from a stack to a list? Why? These are _really_ different > abstractions. A stack is monolithic; a list polylithic. The only time > I ever use a list is to implement a monolithic collection like a stack > or queue or container. > > Like an array, a list is a data structure that should only be used to > implement higher-level abstractions. Never use a list (or array) > directly as a data structure. I guess I rarely use data structures directly now anyways :-), but in any case I am pretty much in agreement with you here. > > If you take a look at the collection library at > > http://www.best.com/~bpr/agl.html which is also "tagged-type-free", > > you'll see that I copied from the C++ STL, and named the iterators > > based on the kinds of iteration they support, Unidirectional, > > Bidirectional, Random_Access, etc., rather than on the data structures > > they iterate over. This gives you what you are calling "static > > polymorphism", and allows you to write many algorithms in terms of > > iterators alone. > > I see your point of view; let me think about it for a while. I only > implemented simple, one-way iterators (from front-to-back, or > top-to-bottom, etc). > > The implementation of the data structure can really limit what kinds of > iteration it supports. For example, if you want to traverse a stack > from bottom to top, you really need to implement the stack using a > doubly-linked list, and, you have to have to a bottom pointer in > addition to the normal top pointer. > > I'm not even sure some iteration schemes should be allowed. For > example, does it make a lot of sense to have a random-access iterator > for a stack? No. I'd provide a stack adaptor (STL terminology) and apply that to a given collection to provide the desired stack semantics. I haven't finished writing all of the stack/queue/etc. adaptors, since so far this AGL is a one man spare time show (remember, I'm really just a lowly C/Verilog/VHDL programmer) and I have limited time, but I think you can see this isn't conceptually hard. > If so, then what's the point of using an ordered > collection? And how do you implement a random-access iterator for a > stack implemented as a linked list? You don't. > > If you can tolerate reading C++, check out the STL, you'll find that you > > share some design goals with its authors. > > I'd really like to study the STL; I have the Stepanov book. I'd bet I > could learn a lot of cool stuff. > > But, as we have discussed in the past, the STL is a library highly > optimized for programming in C++. Trying to apply STL ideas to Ada95 > would be like trying to translate argot from French to English - how > well does it really translate? As we've dicussed before, you don't translate "word for word", even between very similar languages, or you get oddities like "Can you him tomorrow pick up?" for "Kun je hem morgen afhalen?" you have to have a sense of what translates and what doesn't. The main ideas of the STL translate quite well to Ada 95, some concepts don't need to be translated in the same way, and so on. Remember, the STL is based on earlier attempts in Scheme and Ada 83. Also, very similar libraries were proposed by Bishop (IEEE Transactions on SW Eng v16n4 1990 p389-402) in Ada 83, and I'm also stealing ideas from other sources (Stephen Leake, take a bow), and adding new touches all the time as my knowledge of Ada 95 deepens. But the proof of the pudding is in the source code, so if you have some question about whether the library maps well to Ada, see the source. -- Brian PS: Its working on iteration libraries that made me something of a downward-closure fanatic. Sure, I can do lots with generics, but a genuine downward closure feature in Ada would make lots of code less clunky. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-27 0:00 ` dennison 1998-07-27 0:00 ` Brian Rogoff @ 1998-07-28 0:00 ` Norman H. Cohen 1998-07-28 0:00 ` Matthew Heaney 1998-07-28 0:00 ` Stephen Leake 1 sibling, 2 replies; 138+ messages in thread From: Norman H. Cohen @ 1998-07-28 0:00 UTC (permalink / raw) dennison@telepath.com wrote in message <6pirk1$iar$1@nnrp1.dejanews.com>... >Again, you have encoded the fact that it is a type in the type's name. I don't >need that information, and it leads to really stupid looking things like >"Command_Type_Type". Consider Command_Variant_Type, or Command_Format_Type, or Command_Kind_Type. The _Type suffix serves not only to announce "This is a type name," but to leave other parts of the name space available for other purposes, e.g. for a variable or formal parameter named Command_Kind, of type Command_Kind_Type. -- Norman Cohen ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` Naming of Tagged Types and Associated Packages Norman H. Cohen @ 1998-07-28 0:00 ` Matthew Heaney 1998-07-28 0:00 ` Stephen Leake 1 sibling, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-07-28 0:00 UTC (permalink / raw) "Norman H. Cohen" <ncohen@us.ibm.com> writes: > The _Type suffix serves not only to announce "This is a type name," but to > leave other parts of the name space available for other purposes, e.g. for a > variable or formal parameter named Command_Kind, of type Command_Kind_Type. I usually just shorten the object name, so for me it would be Kind, of type Command_Kind. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` Naming of Tagged Types and Associated Packages Norman H. Cohen 1998-07-28 0:00 ` Matthew Heaney @ 1998-07-28 0:00 ` Stephen Leake 1 sibling, 0 replies; 138+ messages in thread From: Stephen Leake @ 1998-07-28 0:00 UTC (permalink / raw) "Norman H. Cohen" <ncohen@us.ibm.com> writes: > dennison@telepath.com wrote in message <6pirk1$iar$1@nnrp1.dejanews.com>... > > >Again, you have encoded the fact that it is a type in the type's name. I > don't > >need that information, and it leads to really stupid looking things like > >"Command_Type_Type". > > > Consider Command_Variant_Type, or Command_Format_Type, or Command_Kind_Type. > > The _Type suffix serves not only to announce "This is a type name," but to > leave other parts of the name space available for other purposes, e.g. for a > variable or formal parameter named Command_Kind, of type Command_Kind_Type. I'll go with Ted Dennison here, partly. I use _Type, and I often run into hardware descriptions of the form "register x bits 1 .. 3 store the command type", so the natural name for this object's type is Command_Type_Type. I usually change the name to Command_Label_Type; I'm more commited to _Type than to matching the hardware documentation. That is bolstered by the fact that I have yet to find a hardware manual with a clear, consistent naming convention, so I don't mind "fixing" it. -- Stephe ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-27 0:00 ` dennison 1998-07-27 0:00 ` Stephen Leake @ 1998-07-28 0:00 ` Matthew Heaney 1998-07-28 0:00 ` Jean-Pierre Rosen 1998-08-06 0:00 ` Robert A Duff 2 siblings, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-07-28 0:00 UTC (permalink / raw) dennison@telepath.com writes: > Be careful. While this may be a nifty convention for ending discussions about > the U.S. constitution, the Ada language designers aren't yet dead. In fact, > they are still around and reading c.l.a. In my experience they have a rather > annoying habit of piping in and disagreeing with me when I was sure they'd > agree. :-) Read the RM. Show me one place in the RM where a type is named "Instance." If the language designers had intended for "type Instance is ..." to be the convention, then surely Text_IO.File_Type would have been named that way! ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` Matthew Heaney @ 1998-07-28 0:00 ` Jean-Pierre Rosen 1998-07-28 0:00 ` Matthew Heaney 0 siblings, 1 reply; 138+ messages in thread From: Jean-Pierre Rosen @ 1998-07-28 0:00 UTC (permalink / raw) Matthew Heaney a �crit dans le message ... >dennison@telepath.com writes: > >> Be careful. While this may be a nifty convention for ending discussions about >> the U.S. constitution, the Ada language designers aren't yet dead. In fact, >> they are still around and reading c.l.a. In my experience they have a rather >> annoying habit of piping in and disagreeing with me when I was sure they'd >> agree. :-) > >Read the RM. Show me one place in the RM where a type is named >"Instance." The RM has many qualities, but it is certainly not intended to be used as an example ! For example, it uses "with P; use P;" in every example, which lead people to believe that the use clause had to be placed after the with, which lead in turn people to forbid the use clause. Here, examples in the RM had the effect of *defeating* the intended purpose of a language construct! >If the language designers had intended for "type Instance is ..." to be >the convention, then surely Text_IO.File_Type would have been named that >way! The purpose of this convention is restricted to OOP programming, and AFAIK File_Type is not (visibly) tagged. But the important thing is NOT that the name is "instance", "object", "T" or "gizmo". The important thing is that there is a distinct identifier for the main type of a package, and that the same identifier is used for all "class packages", generic or not. -- ---------------------------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://perso.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` Jean-Pierre Rosen @ 1998-07-28 0:00 ` Matthew Heaney 1998-07-28 0:00 ` dennison 0 siblings, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-07-28 0:00 UTC (permalink / raw) "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > >Read the RM. Show me one place in the RM where a type is named > >"Instance." > The RM has many qualities, but it is certainly not intended to be used as an > example ! I take the opposite position, and try to follow the spirit of the conventions in the RM. Perhaps this is the real basis of our disagreement. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` Matthew Heaney @ 1998-07-28 0:00 ` dennison 1998-07-29 0:00 ` Matthew Heaney 1998-07-30 0:00 ` Robert Dewar 0 siblings, 2 replies; 138+ messages in thread From: dennison @ 1998-07-28 0:00 UTC (permalink / raw) In article <m3d8aqxtau.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: > "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > > > >Read the RM. Show me one place in the RM where a type is named > > >"Instance." > > The RM has many qualities, but it is certainly not intended to be used as an > > example ! > > I take the opposite position, and try to follow the spirit of the > conventions in the RM. Perhaps this is the real basis of our > disagreement. Does that mean back in the Ada83 days you made all your identifiers all upper- case? Yuk. T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` dennison @ 1998-07-29 0:00 ` Matthew Heaney 1998-07-30 0:00 ` Robert Dewar 1 sibling, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-07-29 0:00 UTC (permalink / raw) dennison@telepath.com writes: > > I take the opposite position, and try to follow the spirit of the > > conventions in the RM. Perhaps this is the real basis of our > > disagreement. > > Does that mean back in the Ada83 days you made all your identifiers > all upper- case? Yuk. No. I used strict title format even in Ada 83. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-28 0:00 ` dennison 1998-07-29 0:00 ` Matthew Heaney @ 1998-07-30 0:00 ` Robert Dewar 1998-07-30 0:00 ` Matthew Heaney 1 sibling, 1 reply; 138+ messages in thread From: Robert Dewar @ 1998-07-30 0:00 UTC (permalink / raw) T.E.D. said <<Does that mean back in the Ada83 days you made all your identifiers all upper- case? Yuk. >> Many people preferred this concvention, and manhy still do. It is a bit silly to say "Yuk" at someone else'es conventions, these things are a matter of taste. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-30 0:00 ` Robert Dewar @ 1998-07-30 0:00 ` Matthew Heaney 0 siblings, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-07-30 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: > T.E.D. said > > <<Does that mean back in the Ada83 days you made all your identifiers > all upper- case? Yuk. > >> > > Many people preferred this concvention, and manhy still do. > It is a bit silly to say "Yuk" at someone else'es conventions, these > things are a matter of taste. Fair enough, but in these days of Internet communication, if you write SOMETHING in uppercase, reading it is like being screamed at. Also, humans read mixed-case text faster then all-caps. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-27 0:00 ` dennison 1998-07-27 0:00 ` Stephen Leake 1998-07-28 0:00 ` Matthew Heaney @ 1998-08-06 0:00 ` Robert A Duff 1998-08-06 0:00 ` Matthew Heaney 2 siblings, 1 reply; 138+ messages in thread From: Robert A Duff @ 1998-08-06 0:00 UTC (permalink / raw) dennison@telepath.com writes: > Be careful. While this may be a nifty convention for ending discussions about > the U.S. constitution, the Ada language designers aren't yet dead. In fact, > they are still around and reading c.l.a. In my experience they have a rather > annoying habit of piping in and disagreeing with me when I was sure they'd > agree. :-) :-) I'll just point out that this discussion about type names hinges on whether you're a use-ophile or a use-ophobe. To the former, "X: Instance;" looks silly (or wrong); to the latter, "X: Bounded_Text_Strings.Bounded_Text_String;" looks silly. The strange thing about Ada is that the programmer who writes a package must choose whether use_clauses will make sense (by choosing sensible names for either option), whereas the client of that package gets to choose whether to actually have a use_clause. - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-06 0:00 ` Robert A Duff @ 1998-08-06 0:00 ` Matthew Heaney 1998-08-06 0:00 ` Tucker Taft 0 siblings, 1 reply; 138+ messages in thread From: Matthew Heaney @ 1998-08-06 0:00 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: > I'll just point out that this discussion about type names hinges on > whether you're a use-ophile or a use-ophobe. To the former, > "X: Instance;" looks silly (or wrong); to the latter, > "X: Bounded_Text_Strings.Bounded_Text_String;" looks silly. > > The strange thing about Ada is that the programmer who writes a package > must choose whether use_clauses will make sense (by choosing sensible > names for either option), whereas the client of that package gets to > choose whether to actually have a use_clause. Funny you should bring that up. The more I think about it, the more I think that use-semantics should be the default when you with a package. In other words, the language should have been designed so that use clauses weren't even necessary. Your observation explains why some programmers object to the plural package name convention, saying "Oh but that name just duplicates the type name." They must be use-a-phobics. I'm a use-a-phile, so of course I'd use Bounded_Text_Strings, and wouldn't dream of writing anything but declare X : Bounded_Text_String; begin If you see a declaration like that, then there's a very high probability that type Bounded_Text_String was declared in package Bounded_Text_Strings, which is of course the reason for naming the package that way. Some shops give themselves rules like Thou Shalt Not Use Use, but that rule is misguided. The real rule should be, Thou Shall Make It Easy To Trace A Type Back To The Package It's Declared In. By naming the package the plural of the type name, then the latter rule is satisfied, in spite of use being used. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-06 0:00 ` Matthew Heaney @ 1998-08-06 0:00 ` Tucker Taft 1998-08-31 0:00 ` Matthew Heaney 0 siblings, 1 reply; 138+ messages in thread From: Tucker Taft @ 1998-08-06 0:00 UTC (permalink / raw) We have been quite happy for the past 15 years (and > 1M SLOC) using the with/rename approach, exemplified by: with Ada.Strings.Bounded; ... package ASB renames Ada.Strings.Bounded; ... X : ASB.Bounded_String; ... if ASB.Length(X) = 0 then ... This makes it very easy to follow all references, without overwhelming the user with repetitive, long-winded package names everywhere. All of the package renames are at the beginning of the compilation unit containing the references. Ideally, the abbreviations are agreed-upon on a project-wide basis. For primitive operators (presuming they have their "intuitive" meaning ;-), I would certainly recommend "use type", but given the above approach, there is almost never a need for "use"ing a package. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar company. ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-08-06 0:00 ` Tucker Taft @ 1998-08-31 0:00 ` Matthew Heaney 0 siblings, 0 replies; 138+ messages in thread From: Matthew Heaney @ 1998-08-31 0:00 UTC (permalink / raw) stt@houdini.camb.inmet.com (Tucker Taft) writes: > We have been quite happy for the past 15 years (and > 1M SLOC) > using the with/rename approach, exemplified by: > > with Ada.Strings.Bounded; > ... > package ASB renames Ada.Strings.Bounded; > ... > > X : ASB.Bounded_String; > > ... > > if ASB.Length(X) = 0 then ... I find this style a bit old-fashioned. First of all, you don't need to tell me every time you invoke an operation on X that the operation is defined in package ASB. I already know that, because you said so in the declaration. So why tell me again, and again, and again...? Of course, you might be using a non-primitive operation defined in some package other than ASB. If the operation is defined in a non-obvious place, then perhaps it does make sense to use an expanded name. But, if the defining packages are carefully named, then that gives you a strong clue that that's where an operation or type is coming from. For example, if I see the declaration X : Bounded_String; ... then I'm going to look at the context clause for a package named Bounded_Strings. The ASB part (or even a fully expanded name) is largely redundant. If the operation is non-primitive (meaning I didn't find it in the package that declared the type), then I'd look for some other clue about its origin. For example, if I saw this Some_Weird_Operation (X); then I'd look for a package called Bounded_String_Utilities, or something like that. Of course, if the (non-primitive) operation is not declared in an obvious place, then it is wise for the writer to give the reader a hint as to it's origin, perhaps using the expanded name notation technique you mention. Remember, types and operations usually go together. Tell me where one is, and that's usually where I'll find the other too. > This makes it very easy to follow all references, without > overwhelming the user with repetitive, long-winded package > names everywhere. All of the package renames are at the > beginning of the compilation unit containing the references. > Ideally, the abbreviations are agreed-upon on a project-wide basis. My personal experience is that abbreviations of this kind are usually unreadable. If a shop is really allergic to use clauses in the context clause, then I prefer this sort of thing: with Ada.Strings.Bounded_Strings; ... X : Ada.Strings.Bounded_Strings.Bounded_String; use Ada.Strings.Bounded_Strings; begin if Length (X) = 0 then ...; The idea is to use fully qualified types in the object declaration, followed by a use clause just prior to the end of the declarative region. A compromise position is: with Ada.Strings.Bounded_Strings; use Ada.Strings; That way I only have to specify the most deeply-nested package in a declaration: X : Bounded_Strings.Bounded_String; use Bounded_Strings; begin But you see even from the example above that expanded name Bounded_Strings.Bounded_String is a bit redundant. If I have a type named Bounded_String in a scope, from what package other then Bounded_Strings can it come from? ^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages
@ 1998-07-26 0:00 tmoran
1998-07-27 0:00 ` dennison
0 siblings, 1 reply; 138+ messages in thread
From: tmoran @ 1998-07-26 0:00 UTC (permalink / raw)
>The addition of tagged types in Ada 95 is good, but it doesn't change
>implementation techniques that much from Ada 83, because you should
>already be using type-based abstractions where that makes sense.
There are some things Ada 95 lets you do that were *extremely*
inconvenient, in Ada 83. Controlled types, which let a task execute
code after an "or terminate" select alternative, and "access T'Class"
which lets you link heterogenous data simply, come to mind. For a
slightly more complex example, a system I'm working on has a
library-level task and task safety (and the OS, in this case) requires
that certain things only be done by that task. Occasionaly, we've
needed to add a new operation. At first we added a new 'entry' and
recompiled the world. Then we realized that there can be one entry
that takes a classwide parameter and calls a standard "Do_Whatever"
procedure, passing that parameter. Now a new operation merely
requires a new descendant of the (abstract) root type with appropriate
information in the new extension part, and an overriding "Do_Whatever"
that will be run from the correct task. No spec changes to the task
and thus no recompilation. Tagged types are a new tool. There's no
requirement to limit their use to what the designers, or OO
philosophy, intended.
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Naming of Tagged Types and Associated Packages 1998-07-26 0:00 tmoran @ 1998-07-27 0:00 ` dennison 0 siblings, 0 replies; 138+ messages in thread From: dennison @ 1998-07-27 0:00 UTC (permalink / raw) In article <6pfs36$8rh@lotho.delphi.com>, tmoran@bix.com wrote: > >The addition of tagged types in Ada 95 is good, but it doesn't change > >implementation techniques that much from Ada 83, because you should > >already be using type-based abstractions where that makes sense. > There are some things Ada 95 lets you do that were *extremely* > inconvenient, in Ada 83. Controlled types, which let a task execute I had need of dynamic dispatching in Ada 83 once. I had to write a big honking case statement that looked like this: case Command.First_Byte is when Command_1 => Command_1_Pkg.Do_It(Unchecked_Convert_To_Command_1_Type(Command)); . . . when Command_120 => Command_120_Pkg.Do_It(Unchecked_Convert_To_Command_120_Type(Command)); end case; I spent *weeks* writing that thing. But a tagged type would have made this 20 page routine a 1-liner! T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum ^ permalink raw reply [flat|nested] 138+ messages in thread
end of thread, other threads:[~1998-09-16 0:00 UTC | newest] Thread overview: 138+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-07-16 0:00 Naming of Tagged Types and Associated Packages taashlo 1998-07-25 0:00 ` Matthew Heaney 1998-07-25 0:00 ` Jean-Pierre Rosen 1998-07-25 0:00 ` Brian Rogoff 1998-07-26 0:00 ` Matthew Heaney 1998-07-26 0:00 ` Matthew Heaney 1998-07-26 0:00 ` nabbasi 1998-07-26 0:00 ` Matthew Heaney 1998-07-26 0:00 ` Robert Dewar 1998-07-27 0:00 ` Jean-Pierre Rosen 1998-07-28 0:00 ` Matthew Heaney 1998-07-28 0:00 ` Jean-Pierre Rosen 1998-07-28 0:00 ` dennison 1998-07-29 0:00 ` Jean-Pierre Rosen 1998-07-29 0:00 ` dennison 1998-07-29 0:00 ` Jean-Pierre Rosen 1998-07-30 0:00 ` dennison 1998-07-30 0:00 ` Jean-Pierre Rosen 1998-07-29 0:00 ` Robert I. Eachus 1998-07-30 0:00 ` Jean-Pierre Rosen 1998-07-30 0:00 ` Robert I. Eachus 1998-07-31 0:00 ` Jean-Pierre Rosen 1998-07-31 0:00 ` Robert I. Eachus 1998-08-01 0:00 ` Jean-Pierre Rosen 1998-08-04 0:00 ` Matthew Heaney 1998-08-04 0:00 ` Jean-Pierre Rosen 1998-08-10 0:00 ` Robert I. Eachus 1998-07-30 0:00 ` Matthew Heaney 1998-07-27 0:00 ` dennison 1998-07-27 0:00 ` Stephen Leake 1998-07-27 0:00 ` dennison 1998-07-27 0:00 ` Brian Rogoff 1998-07-28 0:00 ` dennison 1998-07-28 0:00 ` Brian Rogoff 1998-07-28 0:00 ` Brian Rogoff 1998-07-29 0:00 ` Matthew Heaney 1998-07-29 0:00 ` Brian Rogoff 1998-07-28 0:00 ` dennison 1998-07-29 0:00 ` Matthew Heaney 1998-07-29 0:00 ` Chris Brand 1998-07-30 0:00 ` Matthew Heaney 1998-07-30 0:00 ` dennison 1998-07-30 0:00 ` Matthew Heaney 1998-07-30 0:00 ` dennison 1998-08-01 0:00 ` Simon Wright 1998-08-02 0:00 ` Matthew Heaney 1998-08-03 0:00 ` dennison 1998-08-03 0:00 ` Matthew Heaney 1998-08-04 0:00 ` dennison 1998-08-04 0:00 ` Jean-Pierre Rosen 1998-08-04 0:00 ` Brian Rogoff 1998-08-05 0:00 ` Don Harrison 1998-08-05 0:00 ` Brian Rogoff 1998-08-07 0:00 ` doylep 1998-08-07 0:00 ` Brian Rogoff 1998-08-08 0:00 ` Matthew Heaney 1998-08-10 0:00 ` doylep 1998-08-10 0:00 ` Brian Rogoff 1998-08-10 0:00 ` John Volan 1998-08-10 0:00 ` John Volan 1998-08-11 0:00 ` doylep 1998-08-11 0:00 ` Brian Rogoff 1998-08-13 0:00 ` Robert A Duff 1998-08-13 0:00 ` Brian Rogoff 1998-09-01 0:00 ` Matthew Heaney 1998-09-01 0:00 ` Dale Stanbrough 1998-09-01 0:00 ` Matthew Heaney 1998-09-01 0:00 ` Bob Collins 1998-09-02 0:00 ` Matthew Heaney 1998-09-04 0:00 ` John G. Volan 1998-08-11 0:00 ` Don Harrison 1998-08-11 0:00 ` Pat Rogers 1998-08-11 0:00 ` Don Harrison 1998-09-01 0:00 ` Matthew Heaney 1998-08-13 0:00 ` Robert A Duff 1998-08-13 0:00 ` Brian Rogoff 1998-08-15 0:00 ` Don Harrison 1998-08-15 0:00 ` Jean-Pierre Rosen 1998-08-18 0:00 ` Don Harrison 1998-08-14 0:00 ` Don Harrison 1998-08-17 0:00 ` doylep 1998-08-19 0:00 ` Don Harrison 1998-08-12 0:00 ` Don Harrison 1998-08-08 0:00 ` Matthew Heaney 1998-08-08 0:00 ` John G. Volan 1998-08-09 0:00 ` Matthew Heaney 1998-08-10 0:00 ` John G. Volan 1998-08-11 0:00 ` John Volan 1998-08-11 0:00 ` Don Harrison 1998-08-11 0:00 ` geoff 1998-08-31 0:00 ` Matthew Heaney 1998-08-31 0:00 ` Tucker Taft 1998-09-06 0:00 ` John G. Volan 1998-09-06 0:00 ` Matthew Heaney 1998-09-04 0:00 ` John G. Volan 1998-09-06 0:00 ` Matthew Heaney 1998-09-06 0:00 ` John G. Volan 1998-09-06 0:00 ` Brian Rogoff 1998-09-06 0:00 ` John G. Volan 1998-09-07 0:00 ` Brian Rogoff 1998-09-07 0:00 ` John G. Volan 1998-09-16 0:00 ` Matthew Heaney 1998-09-06 0:00 ` John G. Volan 1998-09-04 0:00 ` John G. Volan 1998-09-05 0:00 ` John G. Volan 1998-09-06 0:00 ` Matthew Heaney 1998-09-06 0:00 ` Matthew Heaney 1998-09-04 0:00 ` John G. Volan 1998-09-05 0:00 ` Matthew Heaney 1998-09-05 0:00 ` John G. Volan 1998-09-05 0:00 ` John G. Volan 1998-09-05 0:00 ` John G. Volan 1998-08-11 0:00 ` doylep 1998-08-07 0:00 ` Don Harrison 1998-08-05 0:00 ` Matthew Heaney 1998-08-07 0:00 ` Don Harrison 1998-08-13 0:00 ` Robert A Duff 1998-08-14 0:00 ` adam 1998-08-14 0:00 ` Don Harrison 1998-08-05 0:00 ` Static Polymorphism (Was Re: Naming of Tagged Types...) Brian Rogoff 1998-08-06 0:00 ` Matthew Heaney 1998-08-06 0:00 ` Brian Rogoff 1998-07-28 0:00 ` Naming of Tagged Types and Associated Packages Norman H. Cohen 1998-07-28 0:00 ` Matthew Heaney 1998-07-28 0:00 ` Stephen Leake 1998-07-28 0:00 ` Matthew Heaney 1998-07-28 0:00 ` Jean-Pierre Rosen 1998-07-28 0:00 ` Matthew Heaney 1998-07-28 0:00 ` dennison 1998-07-29 0:00 ` Matthew Heaney 1998-07-30 0:00 ` Robert Dewar 1998-07-30 0:00 ` Matthew Heaney 1998-08-06 0:00 ` Robert A Duff 1998-08-06 0:00 ` Matthew Heaney 1998-08-06 0:00 ` Tucker Taft 1998-08-31 0:00 ` Matthew Heaney -- strict thread matches above, loose matches on Subject: below -- 1998-07-26 0:00 tmoran 1998-07-27 0:00 ` dennison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox