Re: Types, packages & objects : the good old naming conventions question (without religious ware)

[Stephen Leake <stephen_leake@stephe-leake.org>]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> Stephen Leake schrieb:
>> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>> 
>>> Hibou57 (Yannick Duch�ne) schrieb:
>>>
>>>> There is on the other hand, this other convention, which came from
>>>> Pascal I suppose : the one which ends types name with the suffix _Type
>>> If you can't find a name for an object, ask more questions
>>> about it, its use, its relations, the programmer, its purpose,
>>> his purpose, etc:
>>> What is the role of the object?  Does the role lead to a name?
>> 
>> Why should I have to waste time on this?
>
> Because the time "wasted" on thinking about the roles (properties,
> relations, ...) of named entities in your programs, and
> then not being silent about your results, instead naming the
> entities suitably according to your results, and explicitly
> saying what you mean, is
>
> (a) spent anyway, though to different extents, on this very
>     issue

Yes, but that applies to both the object name and the type name;
making them _different_ requires _extra_ effort.

> P1 (in the kitchen): "P2? Mind giving me that?"
> P2 (in the living room): "What?"
> P1: "That thing over there."
> P2: "Where?"
> P1 (approaches):  "There." (P2 moves) "No, there."
> "No, not that, that!"

This is _not_ a good analogy; "that" is not a subprogram parameter in
the kitchen!

>>     procedure Sort (List : in out List; Order : in Order_Type);
>
> "List" is a darn bad abstraction name here!  

Nonsense; it is _precisely_ what I want; a list of abstract objects.

You can't avoid the naming problem by changing the context!

Here are the similar definitions from
Ada.Containers.Indefinite_Doubly_Linked_Lists. I hope you won't start
arguing that is a bad abstraction.

package Ada.Containers.Indefinite_Doubly_Linked_Lists is

   type List is tagged private;

   generic
      with function "<" (Left, Right : Element_Type) return Boolean is <>;
   package Generic_Sorting is

      function Is_Sorted (Container : List) return Boolean;
   end Generic_Sorting;
end Ada.Containers.Indefinite_Doubly_Linked_Lists;

Note that it uses _Type for Element!

How is that better than this:

package Ada.Containers.Indefinite_Doubly_Linked_Lists is

   type List_Type is tagged private;

   generic
      with function "<" (Left, Right : Element_Type) return Boolean is <>;
   package Generic_Sorting is

      function Is_Sorted (List : List_Type) return Boolean;
   end Generic_Sorting;

end Ada.Containers.Indefinite_Doubly_Linked_Lists;

> (For illustration we could similarly praise a ubuquituous type name
> such as "Bits" when what is meant is
> "Temperature_Sensor.Connector_Bits", say.)

But nothing specific is "meant" here; it is a generic, in the truest
English meaning of that word.

> (Rules here: Bits _of_ something, sensor _of_ something,
> these are examples following Tom Moran's comment, if I'm
> not mistaken. Names Sensor and Bits are really quite abstract.
> I would force them to be used for abstract types' names, at best.)

Yes, if you have a specific context and a specific meaning, then you
should use a specific name. The corollary is that if you have a
generic context, you should use a generic name.

> List in your original example without the Order parameter was
> almost certainly a Partial_Order even without an Order parameter
> in sight (since in the modified example you have given in this
> posting there is an Order parameter).  Next, the List is a partial
> order of element of some type.  Only in a reusable subprogram
> their type, if irrelevant, adds but noise (as per Bob Duff's rule).
> Since there is now an explicit Order parameter, I will assume
> that the List is really just a set of items without an order,
> and the name "List" only alludes to the mode of accessing
> the elements (sequentially, linked in some unknown way).

Ok.

> If I understand "Sort" meant as a generically useful procedure,
> then, as Dmitry has said, the first argument can be named "Container",
> since it contains the elements of the list (the type of Container).

Obviously; that's the approach Ada.Containers takes. It can also be
named "list", since that means exactly the same thing. Or the type can
be named "container", for the same reason.

There is the large risk that one person will decide on :

    procedure Sort (Container : in out List);

and another will choose:

    procedure Sort (List : in out Container);    

Now somebody has to decide, and one has to go back and make lots of
trivial (and therefore error-prone) edits.

I suppose one person could choose List_Type and the other
Container_Type, but at least that's a smaller fix to unify them.

> Without some hint to an order, a type name "List" says enough about
> the structure of the actual parameter (Container).
>
> "Order" is somewhat unspecific.  

Yes, deliberately.

> The "List" context helps when guessing that Order refers to a
> mathematical ordering relation. Its not a call to order, say, in a
> program controlling the president's electronic bell in some
> parliament.

Yes, obviously; this is a programming language context, not "the real
world".

> Inside the procedure, you might want to emphasize the links of
> the elements to be sorted.

Who said this was a linked list? Ada.Containers.Doubly_Linked_Lists
is, my original example doesn't care. I guess you could be refering to
abstract links.

See http://www.stephe-leake.org/ada/sal.html
sal-gen-alg-find_linear-sorted.ads for an abstract sort procedure. It
uses Container and Container_Type; "list" does have the connotation of
"linked list", "container" is slightly more abstract. But I often use
the name "list" for an implementation that happens to be an unbounded
array; "list" tends to imply some access order, meaning there is at
least First, Next, Is_Done. Containers don't have those functions.

> One way to achieve this is to rename the parameter "Container"
> to "Linked_Elements" (I'd think it is somewhat pompous, though.
> The implementer will know how to deal with the name Container.
> The reader of Sort's body will know what Container is, too.
> Because the type name, such as "Linked_List" gives the necessary
> information.)

That would be wrong; you are adding/imposing a structure that is not
necessarily there.

> generic
>     type Less_Equal is new Ordering with private;
> procedure Sort (Container : in out Linked_List);
>
> Is anything lost here?  

Yes! You have lost the fact that this is a generic procedure that
doesn't care about the internal structure of the list. You have also
lost the ability to specify the Order at run-time.

And "less_equal" implies a mathematical sort. All I really need for a
sort that produces a linear order is "goes_before". We tend to map all
things into numbers, so "less_equal" makes sense. But it's really
better to say "A goes before B", instead of "A is less than B".

"Ordering" could also imply a partial order, as for military rank; all
generals first, then all lieutenants, seargents, etc. Less_Equal can
mean that, but "Military_Rank" would be clearer.

>>> Naming conventions always make me think of features
>>> that a language does not offer.  I don't think this is
>>> the case with types and objects in Ada.
>> 
>> It _is_ the case for Ada! The feature "separate name spaces for types
>> and objects" is not offered by Ada. I'm not aware of a language that
>> does offer this feature, but it certainly is within the realm of
>> possibility.
>
> I think Dylan made an attempt, at least if one is satified with "car"
> being in a different namespace than "<car>".

Clearly it's a different name; it's a different lexeme. That's
the same as the _Type convention. 

> I'd still not pick essentially the same name for object Car
> and type Car though. Even if Ada had one namespace for types
> and one for other entities.  An object is never the same
> as a type, therefore it should be possible to distinguish
> the difference using words.

Yes! Car is distinguished from Car_Type, but List is not distinguished
from Container. Thank you for agreeing with me :).

Actually, I disagree with this statement; overloading types and
objects is fine, since the language does make the distinction clear
from context. In Dylan, I would use "car" and "<car>".

It sounds like you don't like overloading in the first place. How
about this: 

    adding integers is never the same as adding float; it should be
    possible to distinguish the difference using words

So you don't like "+" (Left, Right : in Integer) and "+" (Left, Right
: in Float)?

If you do like operator overloading, how is that different from
object/type overloading?

-- 
-- Stephe