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:
> 
>> Stephen Leake schrieb:
>>
>>> Op_1 (onto => list, element => object_1);
>>> Op_2 (from => list, element => object_2);
>>> Op_3 (container => list, element => object_3);
...
> I meant easier in all senses; fewer compiler errors, fewer real
> errors, less development time.

What about the time needed to understand the program,
or to communicate its meaning, and be it just the outlining
of the don't-care parts absent from the naming scheme?

>> I think the ease argument will be interesting if it becomes
>> clear what the Op_N stand for, respectively.
> 
> If you start asking about what they stand for, you've missed the
> point. I should not have to waste time thinking about that; I know

Here we are...  You may know, but I don't; if I am important
as a user of your programs, I'd kindly ask you to have the
knowledge shine through the names.


> they come from the list package, so the type is List_Type, and the
> parameter name is List. Now I can think about the _other_ parameters.

In this case (two things we know: we have a list package and
a list type), it is possible instead to give, first,

  package List is

     type Container is private;

     procedure Sort (Elements : in out Container; ...);

and, second, a rule that forces programmers to use a prefix
in clients, to make sure the type of "Container" can be seen
immediately:

   procedure Some_Client
     (<problem-domain-name> : List.Container; ...);

   Left_Queue, Right_Queue : List.Container;



>> Cf. valid Eiffel:
>>
>>    local
>>       string: STRING
>>    do
>>       ...  -- more uses of string and STRING. Or StrINg.
> 
> That is the argument both for and against case sensitivity.

No, the argument is that a language allowing the same name
("string") to stand for different things, for both objects and
types, in the same scope will necessarily add another dimension
to the confusion space.  Specifically, "string" and "STRING" do
not denote the same thing *even* *though* the language
Eiffel is case insensitive, like Ada.  The lexical overlap
of names in separate name spaces plus the case insensitivity
add to to the combinatorial explosives in front of the
reader.
(Of course, in real life forcing good standalone names
are simply(*) is countered with "works for me".)

procedure Something (List : in out List; ....), with a
namespace for objects and another for types, just places
the burden of disambiguation on the reader. Yes, they need
to do that sometimes; the author might not forsee the
necessity.  To me, it does not matter that the author of
Something happens to know which is which.

Continuing Dmitry's argument

  package List_Package is

      type List_Type is private;


      function List_Function return List_Type;

  end List_Package;

Here, I must choose List_Function because Ada lets me have
only one namespace.  So I need to add noise, but
I (the author) know that the function is just
returning a new List, no need to think of a good name,
since I know what I am doing... What am I doing?

What would clients look like?

-----
(*) "Simply" is a trade mark of Betrand Meyer. :)
(There are simply too many occurrences of "simply" in
OOSC2 to think otherwise...)