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

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

On 11/6/09 11:14 AM, Stephen Leake wrote:

>> 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,
>
> Why is this better? It's just a different convention.   If you follow it
> uniformly, it will be just as good as List : in out List_Type.

The convention differs in that none of the identifiers overlap.
For me, List and List_Type are just not different enough (the first
being a prefix of the second only in a very mechanical sense BTW):
I need to combine programs whose authors have followed
different naming conventions.  In this case I have to take
responsibility for disambiguating all occurrences of "List"
WRT to their denoting a type or an object.

Yes, if one author chooses to name the package "List" and the
type "Container", another chooses type name "List", the situation
is equally imperfect.  But at least, I feel like the authors
have picked names whose differences is more than a dry, formal
suffix like "_Type": the difference is in the "domain part" of
the type name.


>> 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;
>
> What if the problem domain is "any list"? We keep pointing this out,
> people keep ignoring it.


    procedure Some_Client  (Any_List : List.Container; ...);
    procedure Some_Client  (Any_List : List; ...);
    procedure Some_Client  (Any_List : Sequence; ...);


This is what I meant by hinting to the domain. (It seems possible
to argue that the word "Any" has a role to play in type names.
I haven't seen "any" as part of a type name, though, only as a
standalone type name, in Eiffel.)  "Any_List" is just explicitly
referring to "any list"; I find "list" for "any list" leaves
more questions to be asked, given the ubiquitous use of "list".
A resolution requires assuming that some convention can
decide on the interpretation.

At least, "Any", unlike "_Type" is not from the Ada language
vocabulary.


> List.Container is much longer than it needs to be. But that's the
> "don't use 'use'" argument.
>
>>>> Cf. valid Eiffel:
>>>>
>>>>     local
>>>>        string: STRING
>>>>     do
>>>>        ...  -- more uses of string and STRING. Or StrINg.
> Ah; Eiffel has separate type and object name
> spaces. So I don't understand the original example; what was the
> point?

In a dozen or so lines of subprogram text, the sequence of
characters "String" can refer to two different concepts, in Eiffel,
when you have declared string : STRING, an object and a type.
The reader, on seeing "String" in the lines following the
declaration, is forced to infer from context which concept was
meant.  Sure, this is possible, not even difficult if you know
the language, as every Eiffel compiler demonstrates.  But I don't
want to assume the role of the compiler just to see what
"String" stands for.
This is name overloading of two language concepts in the
very same inner scope.  Even when this if formally just
fine, what's the point?


> Yes, this is an example of name overloading. Overloading, like any
> good thing, can be abused.

Assuming separate namespaces for objects and types,
I can imagine programmers who find "string : STRING"
very clever.  Or just a good match for some twisted programming
trick.  Why make cleverness, or the appearance thereof,
easy to achieve?

For comparison, imagine a Prolog program that uses Yellow in the
parameter list and yellow in the definition.  A Prolog fan knows
that "Yellow" is not bound AFAIK, since it starts with a capital
letter "Y"; "yellow", starting with a small "f", must have
been bound somewhere.  In a sense, Yellow and yellow
live in different namespaces.  The image of that definition
does confuse me, but I am not sure whether this style is
frowned upon in the Prolog community.   I hope so.
The rule about upper case first letters for Prolog variables
has been criticized.

>> 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. But it is a very small burden, pretty much the same as having to
> read _Type.

I have to disagree here, for reasons given here and in another post.


> Hmm. I guess you are pointing out that package names, subprogram
> names, object names, and type names all share the same namespace.
> Since we feel the need to add noise to types, why don't we feel the
> same need to add noise to packages and subprograms?
>
> The answer is we just don't :).

True enough.  Yet there are those who feel the need to not
add _Type to type names, too, at least when the suffix
is used to "free" that same name for objects nearby.