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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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/12 Message-ID: <3377E12F.25FF@sprintmail.com>#1/1 X-Deja-AN: 241209487 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-12T00:00:00+00:00 List-Id: Aaron Metzger wrote: > > You really put a different spin on the whole debate with this example. > Up to this point I think people were just expressing different naming > conventions for types and objects in the "problem" space. With > "_Pointer" you are stepping into implementation details. Nope, not at all. See other followups for why "_Pointer" refers to a high-level abstraction. I can be persuaded to substitute it with "_Access" but this just refers to the same high-level abstraction. In Ada83, you may well have been indoctrinated in the idiom that says that access types should be implementation details hidden inside packages. In some cases of abstract data types, that's still quite correct. But object-oriented software tends to get heavy into the use of reference semantics. An "object" (in the OO sense) has an "identity" distinct from its "state". Two objects with the same state are still distinct objects, because their identities are different. Objects tend to cross-reference each other by storing each other's identities (_not_ copying their states). There are many ways such identity references can be implemented, but one very convenient way is with an access type. Therefore, a common object-oriented idiom for Ada95 will be to have a package that implements a notional "class" of objects by declaring a tagged type (preferably limited and private) with an accompanying access type (usually general access to classwide). > Maybe in a > small local scope such conventions won't hurt you too much but I hope > you don't propose suffixes such as _Pointer, (or others that I combat > daily --> _Record, _List, _Array) for any type names that are exposed in > package specs. I can see little justification for marking a type with "_Record", so I agree with you on that. "_List" I would reserve as a marker for some private type (probably from a generic instance) that actually implemented some kind of "list" abstraction. "_Array" I do find to be useful. If an array type is publicly visible in a package spec, I think "_Array" is a perfectly valid marker to put on its name. It tells it like it is: The thing _is_ an "_Array_Type". That's the abstraction clients see: Objects of that type can be indexed and sliced and so forth. Other markers, such as "_Table", "_Vector", "_Matrix", might also be acceptable for a visible array type, but those markers might be even better suited for private types, and anyway, "_Array" just seems more honest. ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------