Re: Naming of Tagged Types and Associated Packages

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

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