Re: Warning: Religious naming convention discussion :-) [was: assign help!!]

["John G. Volan" <johnvolan@sprintmail.com>]

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? :-) ");
------------------------------------------------------------------------