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

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

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

(b) is not wasted: first because of (a), second because
    if you think about the entities, and name them properly,
    the positive effect is the same as in all human
    communication:

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!"
...

Alternatively, P1 could with trained effort name things
and their relations:

P1 (in the kitchen): "P2? Mind giving me the crystal vase
standing on the sideboard next to the door?"


Obviously, the second example shows a naming convention
that is less sloppy, less abstract (than "that", "there")
and more specific.
I am sure P2 will know what to do, because he can
understand and interpret the meaning of well
chosen names, and they are well connected.
P2 of the first example is in a different situation
which is characterized by a waste of energy,
cause by a lack of specific names and good connections.


> answer those questions for this:
> 
>     procedure Sort (List : in out List; Order : in Order_Type);

I had immediately come up with some ideas on seeing this
example (without the Order parameter!) in your other post.

"List" is a darn bad abstraction name here!  (For illustration
we could similarly praise a ubuquituous type name such as "Bits"
when what is meant is "Temperature_Sensor.Connector_Bits", say.)

(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.)

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).

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).
Without some hint to an order, a type name "List" says enough about
the structure of the actual parameter (Container).

"Order" is somewhat unspecific.  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.

Inside the procedure, you might want to emphasize the links of
the elements to be sorted.
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.)

generic
    type Less_Equal is new Ordering with private;
procedure Sort (Container : in out Linked_List);

Is anything lost here?  This is a reusable Sort, then.
The declaration still leaves open whether we can safely assume
that Sort will produce the result in ascending order.


>> 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>".

define method sell(car :: <car>, new-owner :: <string>) => ();
  if (credit-check(new-owner))
    car.owner := new-owner;
  else
    error("Bad credit!");
  end;
end;

(from http://www.opendylan.org/gdref/tutorial/ch03.html)

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.

Here, I'd think about the role of the parameter "car".
There is more information available, the car object has
a role.  Maybe this is better:

define method sell(vehicle-on-sale :: <car>, ...