From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC,T_FILL_THIS_FORM_SHORT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2078dddcdcd8d83 X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: Warning: Religious naming convention discussion :-) [was: assign help!!] Date: 1997/05/11 Message-ID: <3376B522.3EA1@sprintmail.com> X-Deja-AN: 240999201 References: <5kjvcv$evt@news.cis.nctu.edu.tw> <5kn8ko$jcc@top.mitre.org> <1997May7.201035.2439@nosc.mil> <33727EEA.2092@sprintmail.com> <5kuf1j$17vi@uni.library.ucla.edu> <3373666A.31DFF4F5@spam.innocon.com> <3373EAB5.73A0@sprintmail.com> <33755EF7.1A8F@erols.com> Organization: Sprint Internet Passport Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-11T00:00:00+00:00 List-Id: Robert Dewar wrote: > > John G. Volan wrote: > > > But once again, I'd want the rule to be simple and minimalistic: Just > > always mark access types (and access objects) with "_Pointer". > > Bad suggestion. Access types are NOT pointers. They may be implemented using > pointers some of the time (but not all the time -- we often find people > using GNAT being surprised to find that access types are not always > represented using simple pointers in some cases, but of course there is > nothing in the language that suggests or requires that access types be > implemented using pointers). I think you're reading too much into my usage of the word "pointer". I did not mean at all to imply any implementation details by using this word, in fact I had in mind exactly the high-level abstraction of an access type. I'm a bit surprised that "pointers" would somehow be a low-level implementation concept. Ever since my Pascal days, I've always viewed them as quite a high level abstraction. Today, with my experience with Ada, I'd tend to use "Address" for the low-level implementation, and indeed, access types are not necessarily simple addresses. Perhaps your interpretation of "pointer" comes from C, where pointers seem to be treated synonymously with addresses. (Although I'm not so sure about that, aren't C pointers sometimes implemented as an address plus an element index?) In fact, the only reason I would suggest this usage would be when you are providing an abstraction that includes both a designated type and a visible access type -- _both_ as part of the visible interface. Both types would relate to the same concept, but they would still need to be differentiated by each other. So one type must be marked somehow. "_Pointer" seems a convenient marker, but if that hits any raw nerves, how about "_Access"? package Targets is type Target_Type is tagged limited private; type Target_Access_Type is access all Target_Type'Class; ... By the way, this would be a case where my naming convention might relax a bit: Not every variable of Target_Access_Type would necessarily have to be called [Optional_Prefix_]Target_Access. The "_Access" could be dropped if you were in a context where you were only working directly with an access variable, and didn't have to have a separate name for the designated object, e.g.: procedure Do_Something_Classwide (Target : in Target_Access_Type); This is especially true if the access type were anonymous: procedure Do_Something_Primitive (Target : access Target_Type); The only time "_Access" would have to be used in an object name would be in (relatively rare) cases where you needed to name both the designated object and the access object in the same scope. The only difficulty with using "Access" as a marker instead of "Pointer" is that "Access", being a reserved word, cannot stand alone as a variable name. When would you want to do that? Consider a generic: generic type Object_Type (<>) is limited private; type Pointer_Type is access all Object_Type; package Garbage_Collected_Refs is -- by convention, let "Ref" mean "Reference" type Ref_Type is private; function "+" (Pointer : in Pointer_Type) return Ref_Type; function "+" (Ref : in Ref_Type) return Pointer_Type; private type Ref_Type is new Controlled with ... end Garbage_Collected_Refs; The first "+" overloading takes an access value and generates a garbage-collected reference value for it, the second retrieves the access value from a reference. At this level of abstraction, we don't have any particular designated type and access type, so there is no compelling reason to mark the access parameter as anything other than "Pointer". If the convention were to use "Access", then we have trouble: generic type Object_Type (<>) is limited private; type Object_Access_Type is access all Object_Type; package Garbage_Collected_Refs -- by convention, let "Ref" mean "Reference" type Ref_Type is private; function "+" (Object_Access : in Object_Access_Type) return Ref_Type; function "+" (Ref : in Ref_Type) return Object_Access_Type; private type Ref_Type is new Controlled with ... end Garbage_Collected_Refs; It might be misleading in this case to take the suggestion I made above and drop "_Access" from the parameter and just call it "Object". These operations are more concerned with the access value rather than the designated object. > Suffixing access types with _Pointer emphasizes the confusion, and seems > inappropriate to me. It is analogous to saying that all integer types > should be suffixed with > > _Twos_Complement_Bit_String > > or somesuch. Reductio ad absurdum at its finest. :-) > Names should be chosen to emphasize the meaning at an > appropriate level of abstraction, not the low-level implementation > dependent representation. Why, I quite agree, and have already said so several times in this discussion. We merely misunderstand each other as to which words refer to abstractions and which to implementation details. ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: The World's *FIRST* International-Standard OOPL", Disclaimer => "These opinions were never defined, so using them " & "would be erroneous...or is that just nondeterministic now? :-) "); ------------------------------------------------------------------------