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

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

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

> On 11/6/09 11:14 AM, Stephen Leake wrote:
>
>>> 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. 

Surely these are in different packages? Packages Containers, Lists,
and Sequences?

Then it is the package name that gives the domain; that works for me.

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

One reason to use "_Type" is precisely _because_ it means "Ada type";
there's no need to wonder about what it means.

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

So the case is not important; why did you introduce it? 

In another post, someone said Eiffel required <> around types; is that
not true?

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

When designing naming conventions, I always assume you know the
language.

In a language like C, sometimes we use conventions that are not
strictly necessary, because the syntax is so bad.

I have not used Eiffel, but if I assume the syntax distinguishing type
from object is as good as in Ada, then I don't see a problem here.

> 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?

The point, as always in this discussion, is to save time making up
separate names for types and objects.

>> 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?

Good programmers will just find it natural; why introduce twisted
programmers into this?

-- 
-- Stephe